Safety model #

Books are records you answer for — to partners, auditors and tax authorities. The MCP server is therefore designed so that an assistant can be useful without ever being able to silently damage the ledger.

Drafts, then an explicit commit #

Every recording tool creates a transaction in the pending state. Pending drafts can be edited or discarded freely and are invisible to reports. Only post_transaction moves a draft to the ledger, and its description warns the assistant that posting is irreversible — a posted transaction is immutable and can only ever be corrected by a reversing entry.

This mirrors the platform’s own two-step commit, so the assistant works the way a bookkeeper does: draft, review, post.

Dry runs everywhere #

All writes — recording, posting, reconciling — accept dry_run=true. The operation is validated by the real API and rolled back, so the assistant can show you exactly what would happen before doing it.

Read-back verification #

The books API silently ignores unknown request fields, which is dangerous for an autonomous agent: a typo could return a “success” that did nothing. The server defends against this in two ways:

• Tool arguments are strictly validated — unknown or misspelled arguments are rejected rather than dropped.
• After posting, the server reads the transaction back and reports whether is_posted is actually true, instead of trusting the write response.

Human-in-the-loop posting #

Set MICROBOOKS_CONFIRM_POST=1 and the server asks you — through the MCP client, not the model — to confirm every non-dry-run post before it happens. See Configuration.

Scoped, revocable credentials #

The recommended setup authenticates with a personal access token carrying only books:read/books:write. It cannot manage your account, OAuth apps or other tokens, and you can revoke it at any moment from Dashboard → Developers → API tokens — the connection dies immediately.