AgenticBooks

Books that build themselves.

От сообществаРаботаетБез входаГлобальныйБесплатноТолько чтение

Что умеет

  • Get Pnl Report: Generates a profit & loss report for an organisation over a date range, from events that have been classified and (where needed) human-approved. Returns revenue, cost of goods, operati
  • Get Account Balance: Returns current account balances across the organisation's connected money providers. Wise, Meow, and Mercury balances are fetched live from the provider APIs. Stripe balance is d
  • Get Bank Balances: Returns the organisation's bank holdings, ONE line per connected bank (Mercury, Revolut (legacy), Meow, Wise, and one line PER Open Banking connection — an org may hold several bank

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

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

Не нужен: сервер работает без входа

Books that build themselves. Instant financial statements and accounting for AI agents and founders. Connect a source and automatically ship numbers to your agents and accountants.

Как подключить

Как подключить AgenticBooks к Claude

Адрес сервера, который нужно вставить в настройках Claude:

https://agenticbooks--agentic.run.tools

  1. Откройте Claude (сайт claude.ai или приложение для компьютера).
  2. Перейдите в Настройки → Коннекторы (в английском интерфейсе: Settings → Connectors).
  3. Нажмите Добавить пользовательский коннектор (Add custom connector).
  4. Вставьте адрес сервера, скопированный ниже, в поле URL удалённого MCP-сервера и нажмите Добавить.
  5. В чате нажмите + → Коннекторы и включите новый коннектор.

Пользовательские коннекторы доступны на тарифах Free, Pro, Max, Team и Enterprise. На Free можно добавить только один. В Team и Enterprise коннектор сначала добавляет владелец организации в Настройки организации → Коннекторы.

Авторизация

После нажатия Добавить откроется окно входа в сервис. Войдите под своим аккаунтом и подтвердите доступ. Пароль Claude не видит.

Как подключить AgenticBooks к ChatGPT

Адрес сервера, который нужно вставить в настройках ChatGPT:

https://agenticbooks--agentic.run.tools

  1. Откройте ChatGPT в браузере (chatgpt.com). Нужен тариф Plus, Pro, Business, Enterprise или Edu.
  2. Один раз включите режим разработчика: Настройки → Приложения → Дополнительные настройки → Режим разработчика (Settings → Apps → Advanced settings → Developer mode).
  3. Откройте Настройки → Коннекторы и нажмите Создать (Create).
  4. Заполните форму: Название (любое), Описание (одна фраза, что делает сервис), URL MCP-сервера (скопируйте ниже).
  5. В поле Аутентификация выберите OAuth, если сервис требует вход, иначе Нет. Нажмите Создать.
  6. В новом чате откройте + → Приложения/Коннекторы и включите коннектор.

Название раздела у OpenAI менялось (Connectors → Apps/Plugins). Если пункт называется иначе, ищите «режим разработчика» в настройках. В рабочих пространствах Business/Enterprise администратор должен разрешить пользовательские коннекторы.

Авторизация

При первом использовании ChatGPT откроет окно входа в сервис. Войдите и подтвердите доступ.

Как подключить AgenticBooks к Cursor

Адрес сервера, который нужно вставить в настройках Cursor:

https://agenticbooks--agentic.run.tools

Быстрый способ: нажмите кнопку Открыть в Cursor ниже, Cursor сам предложит добавить сервер.

Вручную:

  1. В Cursor откройте Settings → Cursor Settings → MCP и нажмите Add new global MCP server.
  2. Вставьте JSON, скопированный ниже, в открывшийся файл ~/.cursor/mcp.json (для одного проекта: .cursor/mcp.json в корне проекта).
  3. Сохраните файл. Сервер появится в списке MCP; при необходимости пройдите авторизацию по кнопке рядом с ним.

Авторизация

Если сервис требует вход, рядом с сервером в списке MCP появится кнопка авторизации.

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

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

get_pnl_reportGenerates a profit & loss report for an organisation over a date range, from events that have been classified and (where needed) human-approved. Returns revenue, cost of goods, operating expenses, payroll, tax, and FX gain/loss as integer cents, plus derived gross_profit_cents (revenue - cost of goods) and net_profit_cents (gross profit - operating expenses - payroll - tax). Expense fields are positive magnitudes; revenue is signed (refunds reduce it). Events still awaiting review are EXCLUDED from all lines and reported in unclassified_cents with a warning — if the warning is present, the report is incomplete until those events are approved via approve_classification. Use this for "how did we do in <period>" questions; for a full current snapshot prefer get_financial_summary. MULTI-CURRENCY: FX conversion is not enabled yet, so when a period contains events in more than one currency the combined *_cents fields are null (a cross-currency sum would be meaningless) and the real figures are returned per currency in currency_breakdown, each a correct single-currency report.
get_account_balanceReturns current account balances across the organisation's connected money providers. Wise, Meow, and Mercury balances are fetched live from the provider APIs. Stripe balance is derived from the classified event ledger (inbound minus outbound) — its live API balance arrives in v2, so treat it as an estimate. The "cash" provider is the ledger-derived 1100 Cash & Bank balance (debits minus credits) — real cash booked by manual journal entries, so an org tracking cash by hand still shows a position with no bank provider connected. One entry per provider account and currency, amounts as integer cents in each account's own currency. total_usd_cents sums every balance 1:1 regardless of currency, so it is always approximate (approximate is always true until real FX rates are added). For the ledger-derived providers, availableCents and total_usd_cents count only CONFIRMED classifications; amounts still awaiting review are excluded from the total and reported separately as pendingReviewCents (per balance) and pending_review_usd_cents (overall), so a flagged event shows as pending rather than inflating the balance. If a provider could not be queried it is listed in warnings and omitted from the total — check warnings before trusting the total.
get_bank_balancesReturns the organisation's bank holdings, ONE line per connected bank (Mercury, Revolut (legacy), Meow, Wise, and one line PER Open Banking connection — an org may hold several banks, each named, with connection_id, per-connection fetched_at staleness and a shared_accounts count for an account two connections serve, rendered once; plus, when a bank needs reconnecting or was removed but still has booked cash, a residual Open Banking line with connection_id null whose name says "(reconnect required)" or "(no live connection)" — that line is NOT a connected bank), as a LIVE-VALUE view: each bank's booked cash balance — summed from its per-currency cash sub-accounts (e.g. Revolut GBP/EUR/USD collapse into a single Revolut total) — converted to the org home currency at TODAY's FX rate. This is the same number the human dashboard's "Bank balances" card shows. It is deliberately DISTINCT from the balance sheet's booked value (each transaction stamped at its own transaction-date rate); the difference is accumulated unrealized FX. The balance source is the booked general ledger (not a live provider API), so it is reproducible from the ledger. Every connected bank is listed including newly-connected zero-balance ones (book_cents 0). A bank whose currency has no available FX rate shows book_cents null (rate unavailable) rather than a misleading zero. Stripe is a payment processor, not a bank — its money is under get_account_balance / clearing, not here. For live provider API balances or Stripe/cash, use get_account_balance.
get_audit_logReads the append-only audit trail for an organisation, newest first. Each entry says what happened (action, e.g. create/approve/sync/flag), to what (entity_type + entity_id), by whom (actor_type: human/system/api), why (reason), and when (created_at, ISO 8601). Use it to answer "who approved this", "what happened to event X" (filter by entity_id), or "what has the pipeline done recently". Filter with entity_type (e.g. classified_event) and/or entity_id. Paginate by passing the returned next_cursor as cursor; next_cursor is null on the last page. total_count is the full match count ignoring pagination. Detailed before/after state is never returned through this tool.
get_unreviewed_eventsLists classified events the rules engine could not confidently categorise (needs_review = true, not yet synced to the ledger), newest first. The pipeline is PAUSED for each of these until someone approves a category — they are missing from P&L reports and the ledger. Every item carries what an approver needs to decide without further queries: the source system, event type, amount in cents, currency, direction (inbound = money in, outbound = money out), when it occurred, the counterparty, the category the classifier suggested, and flagged_reason explaining why it was flagged. Resolve an item by calling approve_classification with its classified_event_id and the correct category. Paginate via next_cursor; total_count is the full queue size.
approve_classificationApproves one event from the review queue (see get_unreviewed_events) by assigning its definitive account, then resumes the paused pipeline: the event is marked reviewed, its double-entry journal lines are written, an audit trail entry records who approved it and why, and a ledger sync job is queued — all atomically. This WRITES financial data: only call it with an account you are confident in, and pass a reason a future auditor will understand (it is stored verbatim in the audit trail). Fails if the event does not exist, belongs to a different org, or is not awaiting review (e.g. already approved). actor_id is optional — it defaults to the organisation entity, and if provided must belong to this org.
get_pending_by_counterpartySummarises the review queue clustered by counterparty and direction — the exact grain a rule is keyed on. Each group carries the counterparty_key, a human label, direction (inbound = money in, outbound = money out), how many events, and their total in cents. Lets you decide once per vendor instead of per transaction: read this, then call create_counterparty_rule to categorise a whole counterparty (existing pending events and all future ones) in one step. Groups are ordered largest-first.
create_counterparty_ruleCreates (or updates) a persistent per-org rule mapping a counterparty to an account, then BACK-APPLIES it to every pending review event from that counterparty — each is properly approved (journal lines written, audit entry, ledger sync queued), not bulk edited. After this, future events from the counterparty auto-classify and never reach review. This is how you act on get_pending_by_counterparty: "categorise all my AWS as infrastructure" becomes one call. This WRITES financial data — only call it with an account you are confident in. The counterparty is matched on a normalised key, so "AWS, Inc." and "AWS EMEA" resolve to the same rule. Idempotent: re-running updates the single rule and re-approves nothing already approved. actor_id is optional — it defaults to the organisation entity, and if provided must belong to this org. GUARDRAIL (OOB approval): if the rule would back-apply to an unusually large set (many events, a large aggregate, or a large rolling-hour total across recent applies), it returns status "approval_required" and writes ONLY an approval request — YOU CANNOT BOOK IT YOURSELF; confirm:true does not bypass it. Your human gets an email and approves on the dashboard, at which point the action books automatically — do NOT retry the call; verify later by re-reading the books (e.g. get_pending_by_counterparty). If the response says the request was denied recently, do not re-ask for 24h. Small approvals apply immediately (status "applied").
list_counterparty_rulesLists the org's persistent counterparty rules — the learned vendor map that auto-classifies future events so they skip review. Each rule carries its id, the normalised counterparty_key it matches, the direction it is scoped to (inbound = money in, outbound = money out, null = both), the target account (code + name), and when it was created and last updated. Use update_counterparty_rule to re-point a rule or delete_counterparty_rule to remove one — both affect future classification only.
update_counterparty_ruleChanges the target account of an existing counterparty rule. This affects FUTURE classification only: events already booked from this counterparty are NOT re-categorised or re-synced — only events classified after this change use the new account. Writes an audit entry recording the before/after account. Idempotent: setting the account it already has is a no-op. actor_id is optional — it defaults to the organisation entity, and if provided must belong to this org.
delete_counterparty_ruleRemoves a counterparty rule. Future events from this counterparty stop auto-classifying and fall back to the static vendor map or the review queue. Already-booked events are unchanged. Writes an audit entry capturing the deleted rule. actor_id is optional — it defaults to the organisation entity, and if provided must belong to this org.
get_financial_summaryOne-call financial snapshot of an organisation: the current calendar month's P&L (same shape as get_pnl_report), balances across all connected providers (same shape as get_account_balance), unreviewed_event_count — how many events are stuck awaiting classification review — and ledger_sync, the accounting-ledger sync health (events synced / pending / failed against the connected ledger, e.g. QuickBooks). clearing_balances reports the Stripe clearing accounts in cents: stripe_receivable_cents (money Stripe owes, net of fees, before payout) and settlement_in_transit_cents (paid out by Stripe, not yet reconciled to a bank). These are informational, NOT errors or unclassified amounts — a Stripe-only org accumulates settlement_in_transit on purpose (the cue to reconcile payouts to a bank). historical_import reports the 90-day backfill (Stripe): when its status is "running" or "pending" the books are still importing and every figure here will keep rising — say so rather than presenting the numbers as final. START HERE for any briefing, health check, or "how are the finances" question; only fall back to the individual tools when you need a different period, specific providers, or the review queue contents. If unreviewed_event_count is non-zero, the P&L is incomplete — follow up with get_unreviewed_events.
reimport_historicalQueues a historical import for the org over a chosen window: the worker lists the connected account's activity (Stripe charges/refunds/payouts, or Mercury transactions across all accounts) and feeds it through the same pipeline as live webhooks. Safe to call any time — it is idempotent: events already present (from live webhooks or an earlier import) are skipped, never duplicated, so the P&L and ledger are never double-counted. After import, a reconciliation sweep drains fully-settled Stripe payouts out of clearing once their matching Mercury deposit has imported. If the chosen window overlaps an already-completed import, the call returns an overlap_warning and does NOT queue unless confirm_overlap is true (the dedup guard still prevents any double-booking; this is a "did you mean to re-scan?" prompt). Returns the run state; poll get_financial_summary to watch progress.
connect_mercuryConnects the org to Mercury from a read-only, scoped API token the user created in their Mercury settings (Mercury uses a token, not OAuth — there is no redirect). The token is validated against Mercury's accounts endpoint and stored ONLY if it works; an invalid token stores nothing and returns an error. This grants READ access only — balances and transactions — it cannot move money. The token is sensitive: it is vault-encrypted at rest and never returned, logged, or echoed. Optionally include the per-account webhook signing secret (from where the webhook was created in Mercury) to enable live transaction events.
disconnect_mercuryDisables the org's Mercury integration (audit-trailed). Mercury exposes no token-revoke API we can call, so this only disables our connection — to fully revoke access, the user must also delete the token in their Mercury settings.
connect_meowConnects the org to Meow from a read-only API key the user created in their Meow dashboard (Meow uses a key, not OAuth — there is no redirect, and read keys need no IP allowlist). The key is validated against Meow's accounts endpoint and stored ONLY if it works and exposes at least one open deposit account; an invalid key stores nothing and returns an error. This grants READ access only — balances and transactions — it cannot move money. The key is sensitive: it is vault-encrypted at rest and never returned, logged, or echoed.
disconnect_meowDisables the org's Meow integration (audit-trailed). Meow exposes no key-revoke API we can call, so this only disables our connection — to fully revoke access, the user must also delete the key in their Meow dashboard.
get_onboarding_statusSUPERSEDED: prefer get_books_status, which covers connections PLUS every books queue (approvals, adjudications, reviews, transfers) with one prioritised next_step. This tool keeps the pure connect walk; since multi-bank an openbanking entry in connected[] also carries connections[] (one per bank, reconnect-required ones marked). The agent onboarding loop driver: which providers are connected, pending, or degraded (credential rejected by the provider — reconnect required), and the ONE next step to take. Loop contract: call this, do next_step (usually: relay next_step.ask to your human, then call next_step.tool if set), call this again — until next_step.action is 'done'. gate=true means the step is blocked on a human action. If next_step carries a warning, relay it to your human VERBATIM and do not proceed without their explicit confirmation. Reads connection state only — never calls provider APIs.
get_books_statusTHE loop driver — call this first, and again after every action. One call reports every queue (connections + degraded credentials, pending human approvals, onboarding gaps, payout-decomposition adjudications, the classification review queue, suggested transfers, captured documents) and next_step: the ONE thing to do now, from a fixed priority ladder (degraded connections → pending approvals → first-ever connection → adjudications → reviews → transfers → document match proposals → missing receipts → done). Loop contract: call this, do next_step (gate=true means relay next_step.ask to your human and wait; otherwise call next_step.tool), call this again — until next_step.section is 'done'. All sections are always present; an empty section means that queue is clear. pending_approvals are the OOB requests your above-guard calls opened — remind your human, NEVER re-call the refused tool. Supersedes get_onboarding_status (still available for the pure connect walk). Reads state only — never calls provider APIs.
list_chart_accountsLists this org's chart of accounts — every account's code, name, type (income/cogs/opex/asset/liability/equity), P&L rollup bucket, whether it is a protected system account (used by the automatic bookkeeping pipeline; rename-only), whether it is active, and its QuickBooks provisioning status. Use this before add/rename/deactivate to see current codes and statuses.
add_chart_accountAdds a new account to the org chart. You pick the TYPE and NAME; the system auto-assigns the next free code in that type's range (income 4xxx, cogs 5xxx, opex 6xxx, asset 1xxx, liability 2xxx, equity 3xxx), never reusing a retired code, and sets the correct P&L rollup. If QuickBooks is connected the account is provisioned there immediately (provisioning_status active); otherwise it is created locally and stays pending until the next QuickBooks connect. The account is usable for categorisation right away. actor_id is optional — it defaults to the organisation entity.
rename_chart_accountRenames a chart account (system or not). The account CODE never changes. The new name is synced to QuickBooks when the account is provisioned there. Doesn't re-categorise any existing transaction. Audit-trailed. actor_id is optional — it defaults to the organisation entity, and if provided must belong to this org.
set_chart_account_activeDeactivates (active=false) or reactivates (active=true) a chart account. Deactivating hides it from new categorisation but never deletes it — existing transactions keep their account and still appear in the P&L. REFUSED for system accounts (required by the pipeline) and for any account that counterparty rules point at (repoint or remove those rules first — the error says how many). Audit-trailed. actor_id is optional — it defaults to the organisation entity, and if provided must belong to this org.
close_periodRuns the month-end (period-end) close for an organisation: remeasures every open foreign-currency monetary balance (per-bank cash accounts whose currency differs from the home/reporting currency) to the period-end closing rate, and books the difference to 6750 Unrealized FX Gain/Loss — distinct from 6700 realized FX. Each revaluation entry SELF-REVERSES on the first day of the next period, so the next period opens at the original basis. This WRITES financial data. IDEMPOTENT: closing the same period_end twice is REFUSED (it fails rather than double-booking). VALIDATED: a period_end in the future (including the still-running current month) is REFUSED — closing is irreversible (no reopen flow), so only completed months can close; a period_end at or below the current closing watermark is REFUSED as already closed. SOFT CHECK (same as the web close): when unrecorded opening balances would be locked behind this close, the call returns closed: false with opening_balance_warnings and writes NOTHING — surface the warnings to the user and re-call with force: true to close anyway (the check itself fails open on provider outages). A home-currency-only org, or one with no open foreign balances, closes with revalued_account_count 0 and writes no entries. Accounts can be excluded individually via the per-account FX revaluation toggle. Returns the period_end, how many balances were revalued, and the classified_event ids of the revaluation entries (not their reversals).
reclassify_entryChanges the ACCOUNT on an already-posted entry (from the general ledger) and nothing else — amount, currency, and date are facts pulled from the bank and cannot be edited here (there is no parameter for them). The entry's journal lines are rebuilt by relabelling the primary leg, preserving every amount and FX home-stamp, so it stays balanced. An audit_trail entry records who changed it from→to, and a ledger sync is re-queued. GUARDS (no bypass): the entry must be posted (not awaiting review — use approve_classification for that); a manual or multi-leg entry cannot be reclassified (correct it by reversal); and an entry in a CLOSED period is refused (reopen or post a prior-period adjustment). Set create_rule:true to ALSO teach a forward-only counterparty rule so future events from this counterparty book to the new account — past entries are NOT retroactively re-classified. actor_id is optional — it defaults to the organisation entity, and if provided must belong to this org.
list_suggested_transfersReturns the inter-bank transfer matches awaiting confirmation: pairs the matcher thinks are the same money moving between two of the org's OWN connected banks (an outflow on one + an inflow on another). Confirm one with confirm_transfer to book a single P&L-neutral transfer; reject it with reject_transfer if the two events are unrelated. Same-currency high-confidence pairs are auto-booked and do NOT appear here; this is the ambiguous set.
confirm_transferBooks a suggested match as ONE inter-bank transfer between the org's own accounts: debits the destination bank's cash account and credits the source bank's, with NO income or expense (+ a 6400 fee line when the received amount is short by a wire fee). Both legs leave the review queue and a ledger sync is re-queued. CROSS-CURRENCY and foreign-same-currency matches ARE supported: each leg is home-stamped at its own date's rate and the home residual (provider spread / timing) books to realized FX 6700. REFUSED pairs: same-currency with received > sent (cannot balance — reject it and classify the legs separately), and a cross-currency pair whose home amounts diverge past the plausibility bound (the residual would book as a phantom FX gain/loss) — that refusal opens an OOB APPROVAL REQUEST: your human gets an email and approves on the dashboard, at which point the transfer books automatically. accept_large_fx_residual NO LONGER bypasses the bound for agents — do not retry a refused confirm; watch the pending approval in your status tool. GUARDS (no bypass): the link must be one of YOUR org's suggested matches, and both legs are re-verified to belong to your org. actor_id is optional — it defaults to the organisation entity.
reject_transferMarks a suggested match as NOT a transfer: the two events stay in the normal review queue for separate classification, and are freed to be re-matched later. Use this when the matcher paired two genuinely unrelated transactions. GUARD: the link must be one of your org's suggested matches. actor_id is optional — it defaults to the organisation entity.
get_billing_statusThis organisation's billing state. Works in EVERY state — it is never blocked, so you can always ask it why other tools are returning payment_required. States: 'trialing' (free first month), 'grace' (free grace month — everything works; days_until_next_transition counts down to the access pause; if it is small, tell your operator to subscribe at payment_url — $20/org/month), 'walled' (access paused until someone subscribes at payment_url; the books are safe and still ingesting), 'active' (subscribed), 'past_due' (a payment failed; Stripe is retrying and emailing the operator), 'comped' (complimentary — payment_url is null, nothing to pay; if comped_until is set this is a beta-partner comp and that DATE is when the free period ends — days_until_next_transition stays null for comped, so read comped_until; a past comped_until means the beta period is wrapping up and the org enters its 30-day grace period within a day). payment_url is a page for HUMANS: relay it to your operator, never try to complete payment yourself.
list_documentsLists the organisation's captured documents (each row is one stored artifact — a PDF/image attachment or a rendered email body), newest first. status tells you where each is in the evidence pipeline: processing (being extracted), matched (attached to a transaction — matched_event_id says which), awaiting_transaction (no matching bank debit yet; re-checked nightly), match_ambiguous (a PROPOSAL awaiting a decision — proposal.candidate_ids are the possible transactions and proposal.reason says why it was not auto-attached: multi_candidate, fx_band, dkim_fail, or first_sender — the sender domain has no previously confirmed evidence in this org yet, so confirming once establishes continuity for future auto-attaches), extraction_failed, too_large, unsupported. Resolve proposals by calling attach_document with the right candidate. Results are the NEWEST `limit` rows (max 200); total_count may exceed files.length — narrow with the status filter to reach older rows. Documents NEVER create bookings — they are evidence attached to the bank record.
attach_documentAttaches a stored document (from list_documents) to a bank transaction as its evidence — confirming a match_ambiguous proposal (pass one of its candidate_ids) or manually resolving an awaiting_transaction/extraction_failed document. This links evidence only: it NEVER creates or changes a booking. Already-matched documents are refused (attachments are never silently re-pointed). event_id is a classified event id, e.g. from list_documents proposal.candidate_ids or get_unreviewed_events. actor_id is optional and defaults to the organisation entity.
get_transactionThe full story of one transaction (classified event): date, counterparty, amount, direction, account classification with confidence, double-entry journal lines (null when not yet booked), provenance (source, event type, external id), and any attached evidence documents. transaction_id is a classified event id — from get_unreviewed_events, list_documents matched_event_id, or a proposal candidate. Read-only.