accountBalances
Returns a snapshot of every connected account with individual balances and aggregated totals grouped by account type. Parameters: none. Response fields:
Example prompt: “What’s my current balance across all accounts?”
Related: REST - Balances
balanceHistory
Returns historical balances across all connected accounts. Aggregates by default - filter withaccount_ids for specific accounts.
Parameters:
Response fields:
Example prompt: “Show me my net worth trend over the last 6 months.”
Related: REST - Balance History
connectedAccountsLookup
Lists every account link (connection) with provider and status.This returns
id for each link. To get the link_id value used by getPayrollIncome and getBankIncome, call incomeReport and use employments[].link_id from there - that field is curated for the income flow.
Example prompt: “What accounts do I have connected?”
Related: REST - Account Links
transactionHistory
Fetches transactions from all connected bank accounts and combines them into a single report. Descriptions are anonymized for privacy. Parameters:
Response fields:
Example prompt: “Show me all my grocery transactions from the last 2 weeks.”
Related: REST - Transactions
searchTransactions
More powerful thantransactionHistory for targeted lookups. Supports text search, amount ranges, type filtering, and pagination.
Parameters:
Response fields:
Example prompts:
- “Find all transactions over $500 in the last 90 days.”
- “How much did I spend at coffee shops?“
recurringTransactions
Detects recurring patterns from bank data and splits them into inflows (income) and outflows (expenses). Parameters:
Top-level shape:
{recurring_transactions: {outflows: [...], inflows: [...]}, accounts: [...]} .
The accounts[] array (same shape as accountBalances.accounts[]) lists every account referenced by the results, so each account_id can be resolved to a name, mask, and type.
Outflow fields:
Inflow fields: same shape as outflow plus
income_type (e.g. PAYCHECK).
Example prompt: “Show me all my active subscriptions.”
spendingAnalysis
Spending breakdowns grouped by category, merchant, or time period, with trend comparisons. Parameters:INVESTMENT-type accounts (brokerage, crypto, IRA) are always excluded - stock buys, reinvestments, and margin interest are not personal spending.group_by is populated; the other two stay null):
Example prompts:
- “Break down my spending by category this month.”
- “Compare my spending month over month for the last quarter.”
incomeReport
Aggregates income from all connected sources and deduplicates entries that appear in both payroll and bank data. Returns one record per employer or income source. Parameters: none. Response fields:
Example prompt: “What are my income sources?”
Related: REST - Income
getPayrollIncome
Full payroll income report with pay stub history for a single connected payroll account - earnings, deductions, and year-to-date totals for the last 90 days. Parameters:
Response fields:
Example prompt: “Show me my recent pay stubs from Acme Corp.”
getBankIncome
Income analysis derived from bank transactions for a single connected account. Identifies income streams with historical averages, pay frequency, and the transactions used for detection. Parameters:
Response fields:
Example prompt: “Analyze the income deposits in my Chase checking account.”
creditSnapshot
Credit report snapshot: score, accounts, balances, payment history, and derogatory marks. Requires a linked credit report connection - if you don’t have one, returns a message prompting you to connect one instead of an error. Parameters: none. Response fields:
Example prompt: “What’s my credit score, and are there any red flags on my report?“
recategorizeTransaction
Applies an override to a single transaction. Changes the category, renames the merchant as it appears in MyTruv, hides it from spending totals, or flags it as recurring or an internal transfer. Only the fields you pass are changed. After writing, the response surfaces similar transactions from the same merchant so you can optionally extend the change.Pass
confirmed=false (or omit it) on your first call when the user names only a merchant without pointing to a specific transaction. The tool returns candidates without writing. Once the user confirms which transaction they mean, call again with confirmed=true.
Response (write succeeded):
Response (confirmation required):
Example prompts:
- “Change the category on that Costco charge to Groceries.”
- “Rename that AMZN MKTPL transaction to Amazon.”
- “Hide this transfer from my spending.”
bulkRecategorizeTransactions
Applies the same override to multiple transactions at once. Intended as a follow-up torecategorizeTransaction when the user agrees to extend the change to similar past transactions. Accepts up to 200 transaction IDs. For applying a change to all future transactions from a merchant, use createCategorizationRule instead.
All IDs are verified as belonging to the authenticated user before any writes are made. If any ID is not found, the entire call fails with an error.
Parameters:
At least one of
category, merchant_name, hide, mark_recurring, or mark_internal_transfer must be provided.
Response:
Example prompt: “Apply that same Groceries category to the other Costco transactions you found.”
createCategorizationRule
Creates a standing rule so that future transactions from a merchant are automatically categorized. By default the rule also applies retroactively to all past transactions from that merchant. Use this as a follow-up afterrecategorizeTransaction when the user wants the change to stick permanently.
If a rule already exists for the merchant, the tool returns an error with the existing rule ID. Rules can be managed in MyTruv settings; editing or deleting a rule via the MCP is not yet supported.
Parameters:
At least one of
category, custom_merchant_name, hide, mark_recurring, or mark_internal_transfer must be provided.
Response:
Example prompts:
- “Always put Costco in Groceries going forward.”
- “Set a rule so all Venmo transactions are marked as internal transfers.”
excludeRecurringMerchant
Removes an auto-detected merchant from the Recurring tab. This is the only way to drop a merchant that the detector surfaced on its own - marking a single transaction as not recurring withrecategorizeTransaction does not remove the merchant from Recurring, it only affects that one transaction.
The exclusion is retroactive and applies going forward, and it’s reversible: mark the merchant recurring again with recategorizeTransaction or createCategorizationRule to bring it back.
Parameters:
Response:
Example prompt: “HelloFresh isn’t a subscription anymore, don’t track it as recurring.”