MCP Actual
Related Servers
Alternatives to MCP Actual
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityCmaintenanceRead-only MCP server for YNAB that provides tools for budgets, accounts, categories, transactions, and financial summaries via HTTP or stdio.1MIT
- AlicenseAqualityAmaintenanceA Model Context Protocol server for YNAB (You Need A Budget). Enables users to query budgets, accounts, categories, transactions, and more, as well as create, update, and delete transactions and manage scheduled transactions from any MCP client.272MIT
- AlicenseBqualityBmaintenanceMCP server for integrating Actual Budget with Claude and other LLM assistants.17375 npm255TypeScriptMIT
- AlicenseNot gradedqualityBmaintenanceAn MCP server for Actual Budget that enables AI agents to read and manage budget data, including accounts, transactions, categories, payees, and budget envelopes, via a long-lived engine singleton.AGPL 3.0
- AlicenseAqualityBmaintenanceMCP server for Actual Budget that enables AI agents to read accounts, transactions, categories, and budgets, as well as create and update transactions and transfers.111MIT
- FlicenseAqualityCmaintenanceA lightweight MCP server for managing personal finances locally. It allows users to log transactions, view summaries, manage categories, and interact with their budget via any MCP-compatible LLM client.12-
TDQS
Scored across 34 tools
Each tool targets a distinct resource+action, and the descriptions actively police boundaries (e.g., search_transactions is cross-account/filtered vs get_transactions exhaustive per-account; preview_rule_effects is read-only vs apply_rule_actions saves). list_categories/list_category_groups and list_payees/find_duplicate_payees are clearly separated by purpose. No two tools appear to do the same thing.
Strong, consistent verb_noun convention throughout (sync_budget, list_accounts, create_category, update_payee, merge_payees, create_rule, apply_rule_actions). A few deviate into noun/other phrasings (describe_rule_schema, find_duplicate_payees, hold_for_next_month, resolve_name_to_id), but they remain readable and predictable.
34 tools is heavy by the usual 3-15 guideline, sitting well into the 'too many' range. However, the domain is genuinely broad (accounts, categories, groups, payees, rules, transactions, budget months, notes), and each tool covers a distinct operation with little redundancy, making it borderline rather than bloated.
Coverage is thorough across budgeting, categories/groups, payees, rules, transactions, and notes, including lifecycle operations like create/update/merge. Gaps remain: no create/delete transaction and no account create/update (partly API limits noted in descriptions), but core read/cleanup/budgeting workflows are complete.