For AI agents & the people who build them

Payments your agent can run —
and one thing it can never do

Connect Claude, or any MCP client, to FireBuddy and your agent can raise and send invoices, take pay-by-bank payments, chase what's unpaid, reconcile against the bank and summarise VAT — on the merchant's own Fire account. The one thing no agent can do is mark money as received. Only the bank's confirmation can, and that is enforced in the database, not asked of the model.

Connect in two minutes

  1. In Claude, go to Settings → Connectors → Add custom connector and paste: 
    https://mcp.firebuddy.info
  2. Sign in and approve when asked — the OAuth consent mints a labelled API key on the merchant's own API Keys page, where it can be watched (last call, caller, route) and revoked at any time. Or skip OAuth and use a fb_live_… key directly.
  3. Ask for money. “Invoice John €250 for the brake job” is a complete instruction — the tools resolve the client, the next invoice number, the merchant's VAT habits and whether to email it.

Prefer raw HTTP? The same surface is a REST API — documentation · OpenAPI spec · llms.txt.

Seventeen tools

Every tool call is forwarded to the public REST API under the merchant's own key — the MCP layer holds no business logic and can never grant more than that key already could.

The settlement truth model

The risk of wiring an agent into money isn't that it charges the wrong card — there are no cards here. It's that it believes the wrong thing: fulfils an order nobody paid for, or tells a customer they owe money they've already sent. FireBuddy's answer is structural:

Only the bank writes “paid”

A payment reaches status: completed only when Fire confirms that exact payment — enforced by a database constraint (payments_completed_needs_fire), not a convention. No tool, no prompt, no bug can mark money received.

In-flight is explicit

in_flight: true means the payer's bank approved and the money is moving — show “on its way”, stop offering to pay. settled: true is the only field that means money. The payment.authorised webhook always carries settled: false.

Retries are safe

POST /invoices is idempotent by invoice_number; re-sending returns the existing invoice instead of a duplicate. An agent that times out and tries again does no damage.

Never fulfil on authorisation. An authorised payment can still fail. Goods, bookings and access wait for payment.completed — the same rule the database holds FireBuddy itself to.

Things to ask, verbatim

“Invoice Brendan Kelly €236.78 for this month's laundry service and email it to him.”
“Who still owes me money? Chase anyone more than two weeks overdue, gently.”
“Did the €400 from EP-1010 actually land? And what's my VAT position this period?”
“Make a €50 payment link for a deposit I can send on WhatsApp.”

Where it fits — honestly

For: Irish and UK businesses (EUR/GBP) taking payments by bank transfer on their own Fire account — invoices, deposits, bookings, B2B. Fees are a flat €0.30/£0.30 per payment, any size; typical card processing runs 1.5%+ and settles days later, pay-by-bank settles in seconds.

Not for: card checkout, customers outside EUR/GBP, or anyone who wants a PSP to hold their money. FireBuddy is software on the merchant's own regulated account — money never touches us. That's the point.

A payer can be told one true sentence card checkouts can't offer: FireBuddy pages never ask for card details, so any “verify your card” prompt in a FireBuddy flow is fraudulent by definition.