ZenMoney MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ZEN_DATA_DIR | No | Directory where the cache and token are stored (defaults to ~/.config/zen-money-mcp) | |
| ZEN_ENDPOINT | No | ZenMoney endpoint to use: 'ru' or 'app' | |
| ZEN_CLIENT_ID | Yes | OAuth consumer key for your ZenMoney application | |
| ZEN_CLIENT_SECRET | Yes | OAuth consumer secret for your ZenMoney application | |
| ZEN_REDIRECT_PORT | No | Local port for the OAuth redirect URI; must match the redirect URI configured in your ZenMoney application | 53682 |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| zen_syncA | Pull the latest data from ZenMoney into the local cache. Run this before auditing if the data may be stale. full:true re-fetches the entire history. |
| zen_list_categoriesB | The category (tag) vocabulary with hierarchy and human-readable paths. Use the ids when proposing category changes. |
| zen_find_transactionsB | Flexible filtered transaction lookup (newest first). Filter by date range, account, merchant/payee/mcc, uncategorized-only, or needs-review-only. |
| zen_merchant_historyA | Full historical category breakdown for a place (by merchant id, payee text, or mcc): how often each category was used, totals, and recent examples. Use to dig deeper when a review row is ambiguous. |
| zen_review_expensesA | Audit expenses in a date range: returns those that are uncategorized or likely mis-categorized, each with the current category and ranked candidate categories (with confidence) inferred from history at the same place. YOU decide the final category from this evidence, then propose changes via zen_apply_categories. Run zen_sync first if the cache may be stale. |
| zen_apply_categoriesA | Write category changes back to ZenMoney. ALWAYS call with dryRun:true first (the default) to preview before -> after, present that list to the user, and only call again with dryRun:false after the user explicitly confirms. tagId null clears the category. |
| zen_import_statementA | Import missing transactions from an Ozon-bank PDF statement into a ZenMoney account. Deduplicates against existing transactions by date + amount; credit repayments (transfers) are never created. ALWAYS call with dryRun:true first (the default) to preview the plan, present it to the user, and only call again with dryRun:false after explicit confirmation. New transactions are created without a category (run zen_review_expenses afterwards). |
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 7 tools
Core workflow tools (sync, review, apply, import) are clearly distinct, and descriptions explicitly chain them together. The only mild overlaps are zen_find_transactions with its needs-review/uncategorized filters versus zen_review_expenses, and zen_merchant_history versus the evidence already returned by review rows; descriptions largely disambiguate these.
All tools share a consistent zen_ prefix and mostly use verb_noun snake_case (review_expenses, apply_categories, import_statement, list_categories, find_transactions). Minor deviations: zen_sync is a bare verb, and zen_merchant_history is a noun phrase with no verb.
Seven tools is well within the ideal 3-15 range for a focused expense-categorization server. Each tool earns its place in the sync → review → evidence → apply loop, with no redundant entries.
The categorization lifecycle is well covered: cache refresh, filtered lookup, evidence gathering, category vocabulary, dry-run write-back, and statement import. Gaps exist beyond this scope — no account listing, no single-transaction create/edit/delete, and statement import is limited to Ozon-bank PDFs — but agents can work around them for the stated purpose.