Holdings

Name: Holdings
Author: holdings

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

От сообществаРаботаетНужен API-ключГлобальныйБесплатноМожет изменять данные

Что умеет

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

Какие данные видит

Нужен ли аккаунт

Нужен API-ключ из настроек сервиса

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

Список инструментов сервера (14)

Технические названия из tools/list. Нужны только разработчикам.

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.