Amounts are in milliunits, as get_budgets' description states, so a value written through create_transaction or update_category_budgeted is not the number a person types into the app. Splitting follows the API rather than the tool signature: when subtransactions are passed to update_transaction, the top-level amount and category_id are ignored and the total is derived from the subtransaction amounts — worth knowing before an update silently discards the figure you meant. Everything is scoped by budget_id, which get_budgets supplies, so the first call of any session is the same one.
A server over the YNAB API for one authenticated user, exposing budget, account, category and transaction reads alongside transaction and category writes.
- The budget's shape on the way in: get_budgets returns every budget for the authenticated user, get_accounts and get_categories take a budget_id, and get_budget_summary summarises a budget, optionally for one month.
- History filtered the way you would ask for it: get_transactions takes budget_id with optional account_id, category_id, since_date and limit.
- Transaction writes: create_transaction takes account_id, amount, date, payee_name, memo and category_id; update_transaction covers the same ground plus cleared, against a transaction_id; delete_transaction removes one.
- Splits as a first-class shape: create_split_transaction takes a subtransactions list and derives the total from it, and passing subtransactions to update_transaction converts an existing transaction into a split.
- Category management: create_category places a new category into a group_id, and update_category_budgeted sets the budgeted amount for a category_id in a named month.
A YNAB account with an API token, supplied as YNAB_API_KEY.
One command plus a key — uvx ynab-mcp, then supply credentials