Skip to main content
Glama
ninetails-io

gnucash-mcp

post_document

Idempotent

Post a customer invoice, vendor bill, employee voucher, or credit note to A/R or A/P, finalizing the document as an official GnuCash transaction.

Instructions

Post a customer invoice, vendor bill, employee voucher, or credit note to A/R or A/P.

Posting creates a transaction in the A/R or A/P account and makes the invoice official. Once posted, entries cannot be added.

For a foreign-currency document, the exchange rate is etched at posting and cannot be updated retroactively. If the latest price for the invoice currency is more than 7 days from the post date (the GNUCASH_FX_GUARD_DAYS window), posting is refused with a stale_fx_rate error — run create_price for a rate near the post date, then retry, or pass force=True to post with the stale rate (recorded in the response and audit log as fx_stale/"forced"). A rate beyond the 90-day staleness cap cannot be forced.

Args: id: Document ID (e.g., "000001"). post_account: A/R or A/P account path (e.g., "Assets:Accounts Receivable"). post_date: Date in ISO format (YYYY-MM-DD). Defaults to today. due_date: Payment due date (YYYY-MM-DD). Optional. description: Description for the posting transaction. Optional. document_type: "invoice", "bill", "voucher", or "credit_note" — disambiguates when IDs collide. party_type: Owner side, credit notes only. force: Override the stale-FX-rate guard and post with a 7–90 day stale rate. Default False.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
forceNo
due_dateNo
post_dateNo
party_typeNo
descriptionNo
post_accountYes
document_typeNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Addedv1.4.4

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, the description reveals important behaviors: posting creates a transaction, entries cannot be added after posting, the FX rate is etched and cannot be updated retroactively, stale rates are refused with a 'stale_fx_rate' error, force behavior is recorded in the response and audit log, and rates beyond 90 days cannot be forced. No contradiction with annotations.

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?

The description is front-loaded with the action and consequence, followed by a structured Args list. The FX-guard paragraph is dense but every detail is operationally relevant. No filler or repetition of schema defaults is present.

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?

Given this tool's complexity, the description covers preconditions, irreversible effects, failure modes, workarounds, parameter semantics, and recordkeeping implications. An output schema exists, so return-format explanation is unnecessary. The description is complete enough for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden. It adds meaning for all 8 parameters: examples for id and post_account, formats/defaults for dates, allowed values for document_type, and clarification that party_type applies to credit notes only. This far exceeds the bare input 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?

Description names the specific action ('Post') and the exact resources: customer invoice, vendor bill, employee voucher, or credit note to A/R or A/P. It also states the consequence ('makes the invoice official'), which clearly distinguishes this from lifecycle siblings like unpost_document, pay_document, and apply_credit_note.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context for when posting is appropriate: making a document official and creating the A/R or A/P transaction. It also routes to 'create_price' as a workaround in the stale-FX condition, but it does not explicitly contrast this tool with related document-lifecycle siblings such as unpost_document or pay_document.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ninetails-io/gnucash-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server