accountBalances
ChatGPTGet current balances for all connected bank accounts with per-account breakdown. Returns individual account details and aggregated totals by account type. Each account includes: - Account type (checking, savings, credit_card, etc.) - Account mask and nickname, which is the user's own name for it when they set one - Current balance, available balance, and credit limit Accounts the user hid are excluded. Aggregated totals group accounts by type and currency, summing balances. Use balanceHistory instead if you need trends over time. Returns: JSON object containing: - total_accounts (int): Number of connected accounts - accounts (list): Per-account details (type, mask, nickname, balance, available_balance, credit_limit, provider) - aggregated_balances (list): Totals grouped by account type and currency Usage: Use this tool to get a current snapshot of all account balances. Useful for net worth calculations, account overviews, and balance comparisons.
balanceHistory
ChatGPTGet historical balance data showing total assets, liabilities, and net worth over time. By default returns aggregated totals across ALL connected bank accounts. Use account_ids to filter to specific accounts. For per-account current balances, use accountBalances instead. Each data point includes: - Date of the snapshot - Total assets value (sum across matching accounts) - Total liabilities value (sum across matching accounts) - Net worth (assets minus liabilities) Parameters: - date_range (optional): How far back to look - "1M", "3M" (default), "6M", "1Y", or "ALL" - account_ids (optional): Comma-separated account IDs to filter by (get IDs from accountBalances) Use cases: - Visualize net worth trends over time - Track debt payoff progress - Monitor savings growth - Compare financial position across periods - Track a specific account's balance over time
bulkRecategorizeTransactions
ChatGPTApply the same override to multiple transactions in one call. Call this AFTER `recategorizeTransaction when the user agrees to extend the change to similar past transactions, or when the user asks for one change (such as the same note) on a set of transactions searchTransactions just listed. Address the transactions with the selection_id` from the response that listed them; there is no way to pass ids the server has not already shown you, because transcribing them by hand corrupts them.
connectedAccountsLookup
ChatGPTGet a list of all accounts (links) for an applicant using the Truv API. Reference: https://docs.truv.com/api-reference/links/links-list Returns: List of account link objects for the applicant. Each object contains a link_id, provider name, data source type (payroll vs financial_accounts), and status. Usage: Call this first to get link_id values needed by getPayrollIncome and getBankIncome when drilling into income details.
createCategorizationRule
ChatGPTCreate a standing rule so future (and optionally past) transactions for a merchant get the same override. Use after `recategorizeTransaction when the user agrees to apply the change going forward. Pass the merchant_name from the previous response (NOT a custom_merchant_name from a rename). Returns 409-style FastMCPError if a rule already exists for the merchant; list it instead. Recurring status is not set here: use setRecurringMerchant`, which updates in place instead of failing on an existing rule.
creditSnapshot
ChatGPTGet the user's credit report snapshot: score, accounts, balances, payment history, derogatory marks. Returns the credit profile trimmed to the fields worth discussing, with sensitive PII removed (display name kept; no SSN, date of birth, address, or phone): - profile.creditScore and the score model - per report: creditScoreDetails (the factors moving the score), summary (total secured and unsecured debt and counts), inquiries, bankruptcies, and creditAttributes (precomputed stats such as utilization, account age, and counts of delinquent or charged-off accounts) - per-account arrays (creditCards, autoLoans, homeLoans, personalLoans, studentLoans, miscellaneousLiabilities), each with balance, limit, rate, terms, status, the 24-month payment-history grid, and collection / charge-off / delinquency status The payment-history code and accountRating are Metro 2 codes; decode them using the credit decoder in your instructions before quoting anything to the user. Returns: JSON object with the trimmed credit snapshot, or a message if no credit profile is connected.
deleteCategorizationRule
ChatGPTDelete the standing categorization rule for a merchant. Use when the user wants to stop a rule they created: "delete the rule for X", "stop always hiding / always categorizing X". This is also how you truly un-hide transactions that a hide-rule keeps hidden: a per-transaction unhide cannot override a rule (`recategorizeTransaction reports still_hidden_by_rule in that case), so delete the rule instead. Removing the rule stops it from hiding or recategorizing its matching transactions; they follow their bank defaults again. Any separate per-transaction edits stay in place, so a transaction the user hid individually stays hidden until un-hidden on its own (don't claim they are all visible). Deleting is retroactive and destructive, so it is confirmation-gated: call first with confirmed unset (false). If a rule exists the tool returns status="confirmation_required" with the rule and does NOT delete; show the user what will revert and wait for their reply. Only after they confirm, on a later turn, call again with confirmed=true to actually delete. Do not set confirmed=true yourself in the same turn you first surfaced the rule. Editing a rule in place is not supported from chat; to change one, delete it and create a new one with createCategorizationRule`.
getBankIncome
ChatGPTGet bank transaction-based income analysis for a specific connected bank account. Use after incomeReport when you need the full bank-derived income breakdown for a single link. Use the link_id field from the employment entry in the incomeReport response — do not guess it. Returns BankIncomeReport: income sources with historical averages, pay frequency, and the individual transactions used to detect each income stream.
getPayrollIncome
ChatGPTGet full payroll income report for a specific connected payroll account. Use after incomeReport when you need complete pay stub history for a single employer. Use the link_id field from the employment entry in the incomeReport response — do not guess it. Returns the full IncomeCheck response including all statements with earnings, deductions, and YTD totals for the last 90 days.
incomeReport
ChatGPTGet a summary of all income sources from connected payroll and bank accounts. Aggregates income from all connected sources and deduplicates entries that appear in both payroll and bank data. Returns one slim record per employer/income source. Data sources: - "payroll": Income from connected payroll providers (ADP, Gusto, etc.) - "financial_accounts": Income derived from bank transaction analysis Returns: JSON object containing: - employments (list): One entry per income source with: - link_id: use this directly with getPayrollIncome or getBankIncome - data_source, provider, company, income, income_unit - pay_rate, pay_frequency, is_active, job_title, job_type - start_date, end_date, bank_income_category - statement_count: number of pay statements available - summary: total_employments, payroll_sources, bank_sources, deduplicated_bank_sources, connected_bank_links For full pay stub details use the link_id from each employment to call getPayrollIncome(link_id) or getBankIncome(link_id) directly.
listMyOverrides
ChatGPTList the user's active transaction edits: per-transaction overrides and standing rules. Use this when the user asks "what have I changed?", "which categories did I customize?", or "which merchants do I have rules for?". Every edit is returned with the merchant, date and amount of the transaction it belongs to, so you can name it the way the rest of the app does. Edits whose transaction is no longer in the store are not listed individually: they are counted in `unresolved_count`, because an id on its own says nothing to the user.
recategorizeTransaction
ChatGPTApply a per-transaction override: change category, rename merchant, hide, or flag recurring / internal-transfer. Use the `transaction_id returned by searchTransactions or transactionHistory. Only the fields you set are changed; existing override values on this transaction are preserved. After applying, the response surfaces follow-ups the agent can offer the user: - similar_transactions: other transactions sharing the same merchant in the last 90 days, addressed together by selection_id. If the user wants to apply the same change to those, call bulkRecategorizeTransactions with that selection_id; never retype the ids. - rule_exists: whether a standing rule already covers future transactions for this merchant. If false, call createCategorizationRule` to make the change stick going forward.
recurringTransactions
ChatGPTGet recurring transactions (subscriptions, bills, and income) from connected bank accounts. Identifies and returns recurring financial patterns including: - Outflows: Recurring expenses like subscriptions (Netflix, Spotify), bills (rent, utilities), memberships - Inflows: Recurring income like salary, freelance payments, dividends Each recurring transaction includes: - Source name and ID - Average amount and frequency - Status (active, inactive, irregular) - Category and account information - Historical transaction list - First detected and last transaction dates The response also includes an `accounts list covering every account referenced by an inflow or outflow, so each item's account_id can be resolved to the account's name/mask/type against accounts[].id without a second lookup. **Parameters:** - status` (optional): Filter by status - "active" (default), "inactive", "irregular", or "all" Use cases: - Find forgotten subscriptions to cancel - Track monthly bills and predict expenses - Verify recurring income sources - Budget planning based on fixed costs
searchTransactions
ChatGPTSearch and filter transactions across all connected bank accounts with flexible criteria. Supports text search, amount ranges, type filtering, and category filtering. Results are paginated — use offset to page through large result sets. Parameters: - query (optional): Text to search for in merchant names, transaction descriptions and memos (case-insensitive substring match). Pass the merchant name as the user says it; it matches even when the bank description spells it differently. - min_amount (optional): Minimum absolute transaction amount (e.g., 50.00) - max_amount (optional): Maximum absolute transaction amount (e.g., 500.00) - transaction_type (optional): Filter by type — "DEBIT" (money out) or "CREDIT" (money in) - categories (optional): Comma-separated category display names to filter (e.g., "Food & Dining,Groceries") - merchant_exact (optional): Exact merchant name (case-insensitive, whole name, not substring). Use to pull all of one merchant's transactions, e.g. every uncategorized charge from a feed card, before recategorizing them. - days (optional): Number of days to look back (default 90, max 365) - sort_by (optional): Sort field — "date" (default) or "amount" - sort_order (optional): Sort direction — "desc" (default, newest/largest first) or "asc" - limit (optional): Max results per page (default 20, max 50) - offset (optional): Number of results to skip for pagination (default 0) Returns: JSON object containing: - total_matches (int): Total number of matching transactions (before pagination) - hidden_matches (int): How many matching transactions the user has hidden. Hidden transactions are never in `transactions and never count toward total_matches. - hidden_transactions (list): The hidden matches themselves, each with merchant_name, date and amount, newest first and capped at five. Read them before answering: if one is the transaction the user asked about, say it is hidden and offer to unhide it. A complete list rules out only that the transaction is hidden; transactions is one page of total_matches, so message says when absence from both lists proves absence from the user's accounts and when to page or narrow instead. - window (dict): the window covered: days, date_from, date_to, and described_as, the phrase to use when naming it. Not the span of the returned rows. - sorted_by (dict): the field and order the results are sorted by. - transactions (list): Paginated list of matching transactions. Each transaction's date is the calendar day (YYYY-MM-DD) in the user's timezone; use it for any date you report so it matches what the user sees elsewhere in the app. - accounts (list): Accounts referenced by the returned transactions; match each transaction's account_id against accounts[].id to resolve account name/mask/type without a separate lookup. - selection_id (str, optional): Handle for the returned page. It is the only way to address these transactions in bulkRecategorizeTransactions; the ids themselves cannot be passed in by hand. - all_matches_selection_id (str, optional): Present only on the first page (offset=0) when it holds fewer than total_matches. Handle for every match of this search (up to 200). Use it when the user asks to change all of them. **Examples:** - Find coffee purchases: query="coffee" - Large debits over $500: min_amount=500 transaction_type="DEBIT" - Recent grocery spending: categories="Groceries" days=30 sort_by="amount" (use display names, e.g. "Food & Dining") - Page 2 of results: query="amazon" offset=20 limit=20`
setRecurringMerchant
ChatGPTAdd a merchant to the Recurring tab, or remove it. Both directions go through this one call, so "stop treating X as recurring" and "treat X as recurring again" behave identically rather than depending on phrasing. It writes a standing merchant-level rule. Per-transaction flagging (`recategorizeTransaction with mark_recurring) does NOT do this; it only affects the one transaction. How far back the change reaches is not always the merchant's whole history: adding a merchant back can be limited to transactions since an existing rule was made. The returned effect says which it is, so read it instead of assuming. Check matched_count` before telling the user it worked. Zero means the name matched none of their transactions and nothing changed on their screen; say so and ask which merchant they meant instead of reporting success.
spendingAnalysis
ChatGPTAnalyzes transaction spending patterns and returns detailed breakdown grouped by category, merchant, or time period. Features: - Group spending by category, merchant, or time period - Calculate trends comparing to previous period - Track spending over time with time series data - Filter by specific categories, accounts, or links - Double aggregation: group by time_period with a secondary breakdown by category or merchant Parameters: - group_by (optional): How to group the data - "category", "merchant", or "time_period". Defaults to "category". - time_period (optional): Time bucket size - "day", "week", "month", "quarter", or "year". Defaults to "month". - link_id (optional): Filter to specific link ID (defaults to all applicant's links) - start_date (optional): Start date in YYYY-MM-DD format (defaults to 3 periods back, minimum 90 days: day/week/month=90 days, quarter=270 days, year=1095 days) - end_date (optional): End date in YYYY-MM-DD format (defaults to today, cannot be in the future) - account_ids (optional): Comma-separated account IDs to filter (defaults to all user-selected accounts) - categories (optional): Comma-separated category display names to filter (e.g. "Food & Dining,Groceries") - min_total_amount (optional): Minimum spending amount to group separately (defaults to $50, lower amounts grouped as "Other") - secondary_group_by (optional): "category" or "merchant" — only valid when group_by=time_period. Returns a top-10 breakdown within each time period. Examples: - Group by category: group_by=category time_period=month - Filter by date range: group_by=merchant time_period=week start_date=2024-01-01 end_date=2024-01-31 - Double aggregation: group_by=time_period time_period=month secondary_group_by=category Note: Transactions from INVESTMENT-type accounts (brokerage, crypto, IRA, etc.) are always excluded — stock purchases, short sales, dividend reinvestments, and margin interest are not personal spending. Passing an investment account ID in account_ids will therefore return empty results for that account. DEBIT transfers to investment platforms (Wealthfront, Robinhood, Fidelity, Schwab, Vanguard, Coinbase, etc.) are also excluded even when the investment account itself is not connected. The matching uses merchant name and description patterns, guarded against known false positives (e.g. "Les Schwab Tires", "Fidelity Life Insurance"). CREDITs from these platforms (withdrawals, dividends) are kept — they are real cashflow into the user's spending accounts.
transactionHistory
ChatGPTRetrieve all bank accounts and transactions from all connected bank accounts. This tool automatically fetches transactions from all connected bank accounts and combines them into a single report. Names in transaction descriptions are anonymized for privacy.
