CountBean
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| COUNTBEAN_BOOK_KEY | Yes | The Countbean book key (cbk_...), obtained from the Connect Claude section at app.countbean.com. | |
| COUNTBEAN_BOOK_TOKEN | Yes | The Countbean book token (bok_...), obtained from the Connect Claude section at app.countbean.com. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| connect_bookA | Connect this plugin to a hosted Countbean book, permanently. Give it the key shown once on your book's page ( Paste both on one line and this tool sorts them out; the |
| start_device_authorizationA | Step 1 of connecting a hosted book: get a code for the user to approve. Returns IMMEDIATELY with a short code and a link. Show both to the user,
then call Deliberately two tools and not one. An MCP tool returns a single result, at the end — so a tool that fetched the code and then waited for approval could never show the code to the person who has to type it. It could only ever expire. That was the first version of this, and it was unusable. |
| await_device_approvalA | Step 2: wait for the user to approve the code from Blocks until they approve, decline, or the code expires. On success the connection is saved and every countbean tool switches to that book. |
| disconnect_bookA | Forget the saved hosted-book connection (the key stays valid; revoke it on the book's page if you want it dead). |
| connection_statusA | Show which book this plugin is talking to, and which config chose it. Answers the question that actually gets asked when something looks wrong: not "is it configured" but "WHICH of my configs won". Environment beats a .env, which beats the saved connection. |
| create_bookA | Initialise a new, empty cloud book (git-backed Beancount ledger). Safe to call once per book; errors if a book already exists at the location. |
| book_statusA | Summarise the current book: location, account count, balances, last commits. |
| add_transactionsA | Append one or more transactions (raw Beancount syntax) to the book. The text is validated with bean-check and only committed if valid; on failure nothing is written and the validation errors are returned. Postings must balance. Open any new accounts first (open_accounts). |
| open_accountsB | Add account Example: |
| add_directivesA | Append arbitrary Beancount directives (auto-routed by kind) and commit. Use for batch setup ("set up my whole situation"): opens, balances, transactions and prices in one validated commit. |
| list_accountsA | List every account currently open in the book. |
| get_ledgerA | Return the full plain-text ledger (accounts, transactions, prices). |
| run_queryA | Run a Beancount Query Language (BQL) query and return CSV-style rows. Example: |
| balancesA | Show balances grouped by account, optionally filtered by a regex.
|
| assess_bookA | Review the book and return COMPUTED facts about it as JSON. Coverage, monthly income/expense, cash, run rate and runway, category shares, month-over-month movers, unusually large postings, and data-quality flags. Read this and report it. Do NOT compute your own figures from it, do not
extrapolate past the coverage window, and do not turn a Every month is marked |
| propose_transactionsA | Parse a bank statement (CSV or OFX/QFX) into PROPOSED transactions. THIS TOOL NEVER WRITES. It returns proposals as JSON;
WHAT YOU MUST DO WITH THE RESULT
Overrides, all optional: amount_shape ('signed' | 'debit_credit' | 'balance'), columns (a JSON object like {"date": "Posted Date", "amount": "Amount"} — header names or 0-based indices), date_format (strptime), delimiter, decimal_separator ('.' or ','), sign ('normal' | 'inverted'), opening_balance (for a running-balance file whose first row has no predecessor), counter_account, currency, file_format, content_encoding. |
| generate_reportB | Generate a financial report from the book. format: 'html' (styled, self-contained) or 'xlsx' (Excel workbook with Balance Sheet, Income Statement and Transactions sheets). Returns the path to the written file. |
| stage_receiptA | Store a receipt photo or PDF as evidence and return a reference to it. Call this FIRST, before proposing anything. A receipt is the source document for the entry it becomes, and an entry whose evidence was thrown away is a promise we cannot keep two years from now. Give it EITHER Returns JSON with the bucket key and the content hash. Pass both to
|
| propose_receipt_transactionA | Turn what you read off a staged receipt into a PROPOSED transaction. You supply the reading and, for every field, how sure you are of it on a 0.0-1.0 scale. Be honest about the confidences — they are the whole mechanism. Anything below the floor comes back flagged rather than as a value, and the floor can be raised by argument but never lowered, so a low confidence is not a suggestion.
Returns JSON. It NEVER writes. Show the person the merchant, the date and
the total, ask about anything flagged, and only then pass |
| historyA | Show the book's git history (each AI or human change is one commit). |
| revertA | Revert a specific commit (undo a change), creating a new commit. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 21 tools
Some overlap exists: add_transactions and add_directives can both commit transactions, and open_accounts overlaps with add_directives for account opens. The descriptions do clarify intended use cases, but an agent could still hesitate between these pairs.
Most tools follow a clear verb_noun pattern (connect_book, add_transactions, open_accounts, run_query), but a few are bare nouns (balances, history, book_status, connection_status). The device-auth tools also mix 'authorization' and 'approval' terminology, though the overall pattern remains readable.
With 21 tools, the server is in the heavy range, though the count is justified by the two-step auth flow and separate workflows for statements, receipts, and reporting. Still, some consolidation (e.g. merging open_accounts into add_directives) could tighten the surface.
The tool set covers the full bookkeeping lifecycle: connecting and creating books, adding validated transactions and directives, opening accounts, querying balances, generating reports, proposing from statements and receipts, and undoing changes via history/revert. No critical operations are missing for the stated purpose.