Holdings

Name: Holdings
Author: holdings

Let your AI send invoices and take payment - card or ACH.

CommunityOnlineAPI key requiredGlobalFreeCan modify data

What it can do

Resolve Action: Turn a natural-language request into candidate Holdings actions. Use when the user's intent is ambiguous; show the candidates as options. No side effects.
Prepare Action: Collect fields and PREVIEW an action. Returns either the missing fields to ask the user, or a humanized preview plus a confirmationToken. For a write you MUST get approval before execu
Execute Action: Execute an action. For a WRITE, pass the actionId from prepare_action (AFTER the user approved the preview) — that alone is enough; do not resend fields or the token. Reads execute wit

What data it sees

Do you need an account

An API key from the service settings is required

Let your AI send invoices and take payment - card or ACH. Free.

Server tool list (14)

Raw names from tools/list. Only developers need these.

resolve_action	Turn a natural-language request into candidate Holdings actions. Use when the user's intent is ambiguous; show the candidates as options. No side effects.
prepare_action	Collect fields and PREVIEW an action. Returns either the missing fields to ask the user, or a humanized preview plus a confirmationToken. For a write you MUST get approval before execute_action. Use details the user ALREADY gave (e.g. a named client) — don't re-ask; pass them and let the server resolve/confirm. Include ONLY fields the user asked for; any optional add-ons the preview lists (tax, billing address, PO, dates, terms) are an OFFER, never auto-add them. CRITICAL: present preview.body to the user EXACTLY as returned — copy it verbatim inside a fenced code block (```), preserving every line break and space. Do NOT reword, summarize, reformat, add a preamble, restate it, or drop any lines. Then show confirm.prompt on its own line below the block. Never fabricate a confirmationToken.
execute_action	Execute an action. For a WRITE, pass the actionId from prepare_action (AFTER the user approved the preview) — that alone is enough; do not resend fields or the token. Reads execute with operationId + fields. Present the returned message to the user VERBATIM, preserving line breaks (including any 'Next:' block); do not reword or drop lines. If the response includes nextActions, OFFER those as options — do NOT perform any of them (e.g. sending after creating) unless the user explicitly asks. Each nextActions entry may carry an `explainer` (what that follow-up does + its consequences/conditions) and pre-filled `fields`: if the user ASKS what an offered action will do, answer from its explainer WITHOUT calling prepare/execute; when they choose it, use its fields to prepare it. Do exactly the one action requested.
list_invoices	List invoices (optionally by status). Read-only. --- Agent instructions --- # List Invoices — Agent Instructions Read-only. No confirmation needed. ## When to use - To answer "what's outstanding / unpaid?", "show my invoices". - To find an invoice's number/id before a write (send, update, void, payment). ## Rules - Optional `status` filter (e.g. draft, sent, paid, overdue). Pass it when the user narrows ("unpaid ones"). - Present the returned summary as-is — no JSON, no field names, no UUIDs. - Use this to disambiguate before a write instead of guessing an id. ## Good > User: "which invoices are unpaid?" → `listInvoices { status: "unpaid" }` → summarize. ## Bad - ❌ Asking the user for an id you could look up here.
get_invoice	Get one invoice by id or number: line items, totals, who it's for (name + email), a status callout (e.g. overdue / paid / due soon), suggested follow-ups, and a link to its PDF. Relay the callout and offer the follow-ups. Read-only. --- Agent instructions --- # Get Invoice — Agent Instructions Read-only. No confirmation needed. ## When to use - To show the details/status of one invoice by number or id ("what's on INV-1042?"). - To check current state before/after a write. ## Rules - Accepts a human number ("INV-1042") or id — pass what the user said. - Present the returned details in plain language; don't surface UUIDs. - Say who it's for. The summary includes a `For: <name> · <email>` line — relay the client's name AND email so the user knows the recipient without opening the invoice. If only one is on file, show what's there. - Be helpful, not terse. The server computes a status callout (e.g. "⚠️ $1,500.00 outstanding — 14 days overdue" or "✅ Paid in full") and, when the response includes a `Next:` block or `nextActions`, the follow-up actions this invoice invites. Relay BOTH: show the callout, then OFFER every follow-up as an option. - Do NOT perform any follow-up (sending a reminder, recording a payment) unless the user explicitly asks. Offer; wait for the user to pick. - The response includes a short-lived link to the invoice PDF (📄 Invoice PDF). If the user asked to see the invoice, hand them that link; hosts that render MCP resource links will attach the PDF automatically. ## Good > User: "what's the balance on INV-1042?" > → `getInvoice { id: "INV-1042" }` > → Give the balance + status, relay the ⚠️/ℹ️ callout, THEN offer the `Next:` > follow-ups ("Send a reminder", "Record a payment") and ask which they want. ## Bad - ❌ Demanding a UUID when the user gave a number. - ❌ Dropping the callout or follow-up offers for a bare one-liner. - ❌ Recording a payment / sending a reminder because it was listed as a next step.
list_quotes	List quotes/estimates (optionally by status). Read-only. --- Agent instructions --- # List Quotes — Agent Instructions Read-only. No confirmation needed. ## When to use - To answer "show my quotes/estimates", "which quotes are still open?". - To find a quote's number/id before a write (send, update). ## Rules - Optional `status` filter (draft, sent, accepted, declined, expired). - Present the summary as-is; no UUIDs. ## Good > User: "any open quotes?" → `listQuotes { status: "sent" }` → summarize. ## Bad - ❌ Guessing a quote id instead of listing to find it.
get_quote	Get one quote by id or number: line items, totals, who it's for (name + email), a status callout (e.g. expired / draft / accepted), suggested follow-ups, and a link to its PDF. Relay the callout and offer the follow-ups. Read-only. --- Agent instructions --- # Get Quote — Agent Instructions Read-only. No confirmation needed. ## When to use - To show one quote's details/status by number or id. - To check state before/after a write. ## Rules - Accepts a human number or id — pass what the user said. - Present details plainly; no UUIDs. - Say who it's for. The summary includes a `For: <name> · <email>` line — relay the client's name AND email so the user knows the recipient without opening the quote. If only one is on file, show what's there. - Be helpful, not terse. The response is not just a field dump — the server computes a status callout (e.g. "⚠️ Expired 3 days ago and still a draft") and, when the response includes a `Next:` block or `nextActions`, a set of follow-up actions this quote invites. Relay BOTH verbatim: show the callout, then OFFER every follow-up as an option the user can pick. - Do NOT perform any follow-up (updating, sending, converting) unless the user explicitly asks. Offer them; wait for the user to choose. - The response includes a short-lived link to the quote PDF (📄 Quote PDF). If the user asked to see the quote, hand them that link; hosts that render MCP resource links will attach the PDF automatically. ## Good > User: "what's on QUO-0007?" > → `getQuote { id: "QUO-0007" }` > → Summarize the line items + total, relay the ⚠️/ℹ️ callout, THEN offer the > `Next:` follow-ups ("Update the quote", "Send it to the client", …) and ask > which they'd like — without doing any of them yet. ## Bad - ❌ Asking for a UUID when the user gave a number. - ❌ Dropping the status callout or the follow-up offers and answering with a bare one-liner. - ❌ Auto-updating/sending the quote because a follow-up was listed.
list_clients	List clients. Read-only. --- Agent instructions --- # List Clients — Agent Instructions Read-only. No confirmation needed. ## When to use - To show the user's clients. - As a picker when a write needs a client and the match is ambiguous — show real names/emails for the user to choose, so you never invent an id. ## Rules - Present names/emails in plain language; never surface UUIDs. - Prefer resolving a client by NAME in the write action itself; use this list only to disambiguate or to confirm a client exists. ## Good > User: "who are my clients?" → `listClients` → list names. > (Ambiguous invoice recipient) → `listClients` → "Did you mean Acme Corp or Acme LLC?" ## Bad - ❌ Showing raw UUIDs to the user.
get_client	Get one client by id. Read-only. --- Agent instructions --- # Get Client — Agent Instructions Read-only. No confirmation needed. ## When to use - To show one client's details (contact info, PO requirement, notes). ## Rules - Identify by name (server resolves it); if ambiguous, use `listClients` to disambiguate. Present details plainly; no UUIDs. ## Good > User: "what's Gamma LLC's email on file?" → `getClient { id: "Gamma LLC" }` → answer. ## Bad - ❌ Asking the user for the client's UUID.
list_payments	List recorded payments. Read-only. --- Agent instructions --- # List Payments — Agent Instructions Read-only. No confirmation needed. ## When to use - To show recorded payments ("what payments came in?", "payment history"). ## Rules - Present amounts and dates in plain language; no UUIDs. - These are bookkeeping records (from `recordPayment`), not live bank movements. ## Good > User: "show recent payments" → `listPayments` → summarize amounts + which invoices. ## Bad - ❌ Implying these represent real-time bank transactions.
invoice_totals	Totals across ALL invoices (no cap): outstanding, overdue, billed, collected, per-status breakdown. Use for 'total up what's overdue'. Read-only. --- Agent instructions --- # Invoice Totals — Agent Instructions Read-only. No confirmation needed. No inputs. ## When to use - Any "total / sum / how much" question about invoices: "total up what's overdue", "how much is outstanding", "what's my unpaid total", "sum of overdue invoices". - Whenever a correct AGGREGATE across every invoice is needed. ## Why not list_invoices - `list_invoices` is capped for browsing. Summing its rows can UNDERCOUNT for a company with many invoices, giving a wrong total. `invoice_totals` aggregates across ALL invoices server-side — it is the correct, complete source for sums. ## Rules - Prefer this over listing-and-summing for any money total. - Money comes back in integer USD cents; present it as dollars in your reply. - Present the returned summary as-is — no JSON, no field names. - `outstandingCents` = balance owed across all non-void invoices. - `overdueCents` = balance owed on invoices whose DUE DATE has passed and still have a balance (what a user means by "overdue"), computed from the due date — not from a persisted status. This is the authoritative overdue figure. - The per-status breakdown reflects each invoice's stored status, which may lag the real overdue picture; trust `overdueCents` for "how much is overdue". ## Good > User: "how much is overdue?" → `invoice_totals` → relay the Overdue figure. ## Bad - ❌ Calling `list_invoices` and adding up rows to answer a total.
get_company	Get the company profile. Read-only. --- Agent instructions --- # Get Company Profile — Agent Instructions Read-only. No confirmation needed. ## When to use - To show the business's own profile (legal name, EIN, entity type, brand color, address). ## Rules - Single resource — no id needed; returns the caller's own company. - Present plainly; treat EIN/legal identity as sensitive (share only what was asked). ## Good > User: "what's our legal name on file?" → `getCompany` → answer. ## Bad - ❌ Reciting the full EIN when the user only asked for the legal name.
capabilities	What this key/company can do right now (scopes, tier, readiness). Read-only. --- Agent instructions --- # Capabilities — Agent Instructions Read-only. No confirmation needed. Requires only a valid key (any scope). ## What this does Your readiness self-check: what this key/company can do right now — scopes, tier, and readiness. ## When to use - Before attempting an action you're unsure the key can perform. - When the user asks "what can you do?" / after a scope/permission error. ## Rules - Use this to explain why something is/ isn't available instead of guessing. - Never claim a capability isn't available unless an Action (this or an error) actually says so. Invoicing/quotes/clients/payments are free-tier — don't invent an accounting/integration prerequisite. ## Good > User: "can you send invoices?" → `getCapabilities` → answer from the returned scopes. ## Bad - ❌ Saying "you need to connect accounting first" for free-tier invoicing.
overview	Company status snapshot: payments readiness, outstanding invoices/quotes, get-started steps, and prioritized next actions. Read-only. Good first call to orient. --- Agent instructions --- # Overview — Agent Instructions Read-only. No confirmation needed. ## What this does A company status snapshot: payments readiness, outstanding invoices/quotes, get-started steps, and prioritized next actions. ## When to use - Good FIRST call to orient at the start of a session or when the user asks "where do things stand?" / "what should I do next?". ## Rules - Use the returned "next actions" to guide the user proactively. - Present the snapshot in plain language; surface the prioritized steps, not raw fields or ids. ## Good > User: "what's the state of my business?" → `getOverview` → summarize status + > top next actions. ## Bad - ❌ Making the user ask five separate questions when overview answers them at once.