A recurring transaction is a rule plus a series of instances, and most implementations only expose the rule — so a month where the subscription did not charge leaves you editing the rule or deleting a real record. Having a per-period skip and a per-period completion keeps the rule intact while recording what actually happened. The instruction on getCategoriesByType is the other useful bit of discipline: telling the caller to fetch valid category names rather than invent one is how a logged transaction ends up in the right place rather than in a category that quietly does not exist.
A personal finance client covering three areas: individual transactions, recurring ones with per-period control, and budgets against categories.
- Transactions with a full lifecycle — retrieve, create, edit and delete, with delete stated as permanent.
- Categories in two kinds: getCategoriesByType is named as the way to get valid category names, and custom categories can be created and removed.
- Recurring transactions handled the way they actually behave — markRecurringTransactionDone for this period and skipRecurringTransaction for the month it did not happen, separate from editing or deleting the recurrence itself.
- Budgets set against categories for a period and read back.
- Currency preference read and set.
BUDGETSCO_ACCESS_TOKEN.
One command plus a key — npx @budgetsco/mcp, then supply credentials