MCP server that keeps the books for your personal and business finances using double-entry accounting — import bank CSVs, categorize spending, reconcile, and generate US Schedule C tax reports, all driven from your LLM.
Bookie has 12 tools with consistent naming (verb_noun pattern) and descriptions present for all. However, schema visibility is limited, tool definitions are registered via `registerXxxTools()` functions but the actual Zod schemas are not visible in the provided source. Parameter descriptions and output schemas cannot be verified. The server uses Zod for validation (good practice) but the schemas themselves are not shown. Descriptions are moderate length (20-100 chars typical) but lack detail on when to use each tool vs. alternatives, prerequisites, or error recovery guidance. No tool annotations (readOnlyHint/destructiveHint) are visible. Error handling approach is unclear from the code provided.
Query account balances from the ledger
Record a transaction in the ledger (from one account to another)
Import transactions from a CSV file using a named profile
Create, update, or delete accounts in the chart of accounts
Create, update, or delete properties (for rental real estate tracking)
Create, update, or delete categorization rules for imports
Create, update, or delete segments (business units for tax reporting)
Input schemas not visible in source code. Tool definitions are registered via `registerXxxTools()` functions but actual Zod schema definitions are not provided. Cannot verify parameter types, descriptions, constraints, or enums.
Tool descriptions are brief (20-100 chars) and lack actionable context. Missing: when to use this tool vs. alternatives, prerequisites, what the tool modifies, error recovery hints. E.g., 'Record a transaction in the ledger' does not explain double-entry semantics, required account types, or what happens on failure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 38 | 2026-07-28+ | v2 |
Generate a monthly reconciliation report
Query transactions from the ledger
Reconcile a bank statement against ledger postings
Generate a US Schedule C tax report for a sole proprietorship
Upload a receipt image or document
No tool annotations visible (readOnlyHint, destructiveHint, idempotentHint). Risk categorization is inferred from tool names and descriptions only. Agents cannot reliably determine which tools are safe to retry or have side effects.
Output schemas not documented. The `gen-tools-doc.ts` script generates docs from live tool registration, but the actual response structures (fields, types, pagination) are not visible in the provided source. Agents cannot plan downstream calls or extract required IDs.
Error handling approach unclear. The `parseToolResult()` test helper catches non-JSON responses and suggests 'likely a server-side error', but no evidence of structured error responses with recovery guidance (e.g., 'User not found. Try search_users()') in the tool implementations.