A wrapper with a tool per entity is easier to discover and is out of date the moment Moneybird adds something. Naming the entity as a parameter keeps the surface at three definitions and reaches everything, with the escape hatch for whatever the pattern does not fit. The cost is that a model has to know that 'sales_invoices' is what the thing is called, which the tool descriptions partly address by listing common paths. For a bookkeeping API where most work is reading, this is a reasonable trade — and worth noting that it is read-oriented, with writes going through the raw request.
A deliberately thin Moneybird client: rather than a tool per entity type, three generic tools reach contacts, sales invoices, estimates and the rest by naming the entity.
- moneybird_list takes the entity type as a parameter, covering contacts, sales invoices, estimates and others through one call.
- moneybird_get fetches a single entity by id.
- moneybird_request makes a custom API request for anything the first two do not cover, with the common paths named in its description.
MONEYBIRD_API_TOKEN and MONEYBIRD_ADMINISTRATION_ID — the administration id because a Moneybird account can hold several sets of books.
One command plus a key — npx moneybird-mcp-server, then supply credentials