Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This MCP server has critical quality gaps. While it covers 52 tools for GnuCash accounting operations, the implementation suffers from severely incomplete parameter documentation, missing input schemas visible in source code, and lack of output schema documentation. The tool list is comprehensive in scope, but the execution quality falls short of production standards. Approximately 90% of tools lack visible parameter schemas in the provided source snippet, and parameter descriptions are absent or minimal across most tools. Error handling is wrapped via a decorator (safe_tool) but recovery guidance is not evident. The server is STDIO-only, which is a hard constraint limiting it to 50 max on protocol readiness.
Missing input schemas for 48 of 52 tools (92%). Source code only shows explicit schemas for list_accounts and list_commodities; 50 tools have no visible schema definitions despite being registered as tools.
Document input schemas for all 52 tools using JSON Schema with type and description for each parameter. At minimum: account_name (string, 2-255 chars), account_type (enum: ASSET, LIABILITY, EQUITY, INCOME, EXPENSE, STOCK, FUND, CASH, CREDIT, etc.), parent_account (string, account name or GUID), commodity (string, e.g. USD, EUR, AAPL). Without schemas, LLMs cannot validate parameter types.
Expand tool descriptions to 50-200 characters. Add WHEN and WHY guidance. Example: 'search_transactions: Find transactions by date range, amount, account, description, or notes. Use this after identifying an account to discover matching transfers or categorize spending patterns. Returns transaction IDs, dates, amounts, and participating accounts for follow-up queries.'
Document output schemas as part of each tool definition. Specify return type (string, object, array), field names (transaction_id, date, amount, account_name, description), and field types. Example: 'Returns an array of {id: string, date: ISO8601, amount: decimal, account: string, description: string, status: 'reconciled'|'unreconciled'|'voided'} with pagination (total, offset, limit).'
Add parameter constraints to descriptions. For example: 'root (optional, string): Filter to a chart-of-accounts subtree by name (e.g. 'Expenses', 'Assets:Bank'). If omitted, returns all accounts.' and 'limit (optional, integer, 1-500, default 50): Max results per page.'
Implement error recovery guidance. Catch common failures and return actionable messages: 'Account not found: "Chequing". Available accounts: Chequing Account, TD Bank Chequing, RBC Chequing. Did you mean one of these?' or 'Invalid status transition: cannot reconcile a voided transaction. Use unvoid_transaction first.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Get detailed information about a specific account.
get_account_slotsread onlysource verified40/100
Get account slots (metadata).
get_audit_logread onlysource verified42/100
Get the audit log.
get_balanceread onlysource verified42/100
Get the balance of a specific account.
get_book_summaryread onlysource verified60/100
Get a compact overview of the entire GnuCash book.
Returns book path, currency, account structure, transaction counts,
key balances, net worth, commodities, and scheduled transactions
in a single text response. Use this first to orient yourself.
get_budgetread onlysource verified42/100
Get a specific budget.
get_budget_reportread onlysource verified42/100
Generate a budget report.
get_latest_priceread onlysource verified42/100
Get the latest price for a commodity.
get_lotread onlysource verified42/100
Get a specific lot.
get_pricesread onlysource verified42/100
Get prices for a commodity.
get_transactionread onlysource verified42/100
Get detailed information about a specific transaction.
List all accounts in the GnuCash chart of accounts.
Returns a compact one-line-per-account format by default.
Use verbose=true for full JSON with guid, type, commodity, etc.
list_budgetsread onlysource verified42/100
List all budgets in the book.
list_commoditiesread onlysource verified70/100
List all commodities (currencies, stocks, etc.) in the book.
Returns a compact one-line-per-commodity format by default.
Use verbose=true for full JSON with fraction, latest prices, etc.
Tool descriptions are sparse or missing for 50 of 52 tools. Only get_book_summary, list_accounts, and list_commodities have substantive descriptions (75+ chars). All others have descriptions of 1-5 words ('Get a specific account', 'Create a new budget'), providing minimal guidance for LLM tool selection.
No output schemas documented. The source code does not show return type documentation for any tool. LLMs cannot predict the structure of responses, forcing them to guess at field names for chaining calls or extracting data.
No parameter descriptions for list_accounts and list_commodities. Even the two tools with visible input schemas (root, verbose for list_accounts; verbose for list_commodities) lack detailed guidance on what values are accepted, expected formats, or when to use each parameter.
No error handling guidance visible. The safe_tool decorator wraps exceptions but does not provide recovery instructions (e.g., 'Resource not found, try searching' or 'Invalid input, allowed values are...'). LLMs receive raw error messages with no next-step guidance.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible. Tools are marked in description text as READ_ONLY, WRITE, or DESTRUCTIVE, but not via structured annotations in the schema. Modern MCP spec requires tool annotations for proper agent planning.
Add structured tool annotations using MCP 2026-07-28 format. Mark destructive operations with destructiveHint=true (delete_account, delete_transaction, delete_budget, close_lot). Mark read-only operations with readOnlyHint=true. Mark idempotent operations (create with duplicate detection, update with same values) with idempotentHint=true.
Document pagination for list tools. Add 'offset' and 'limit' parameters with defaults (e.g. offset=0, limit=50). Return a pagination object: {total: int, offset: int, limit: int, items: [...]}. Prevents context window exhaustion when users have hundreds of accounts or transactions.
Add parameter dependencies documentation. For example, 'replace_splits: If updating an income transaction, you must provide all splits. Omitting a split deletes it, use with caution.' Document mutually exclusive parameters (e.g. user_id vs email) to prevent LLMs from passing both.
Create a per-resource reference document showing which tools operate on each entity (Account, Transaction, Budget, Lot). This helps LLMs compose multi-step workflows (e.g., get_account → list_transactions → reconcile_account → get_balance).
Add dry-run or confirmation support for irreversible operations. Example: 'delete_transaction(id, confirm=false): If confirm=false, returns a summary of what will be deleted. If confirm=true, deletes the transaction and returns the deleted record. Prevents accidental data loss.'
Document natural identifiers accepted by each tool. For example, 'create_transaction: Accepts account_from as account name (string, case-insensitive) or account GUID. Also accepts date as ISO8601 or natural language ('today', 'tomorrow', 'Jan 15'). This matches how users think and speak about their finances.'
Validate and document rate limits or timeouts. If the tool accesses an external service (e.g., price feeds), specify timeout behavior: 'get_latest_price: If the price service is unavailable, returns the last known price with a warning. Timeout is 5 seconds, consider caching for repeated calls.'
Add examples to descriptions using enum constraints instead of example values. Instead of 'status can be pending, active, closed (e.g. pending)', use a Pydantic Field with enum=['pending', 'active', 'closed'] and let the schema speak for itself.