query_transactions
Returns a paginated list of transactions matching the supplied filters. This is the workhorse read tool — almost every agent session goes through it. Scope: Read Mirrors:GET /api/v1/transactions
Parameters
Start date inclusive.
End date exclusive.
Filter to a single account (UUID or short ID).
Filter to all accounts owned by a family member. Attribution-aware — includes transactions attributed to this user via account links.
Filter by category slug. Parent slugs include all children.
Minimum amount (positive = debit, negative = credit).
Maximum amount.
Filter by pending status. Omit to return both.
Filter to flagged transactions (
true) or unflagged (false). Omit to return both. Use flagged=true to retrieve transactions you (or an agent) marked for follow-up via update_transactions.Case-insensitive substring match on
name and merchant_name. Comma-separate values for OR.contains, words, or fuzzy.Exclude transactions whose name or merchant matches this text.
Tags the transaction must have (AND). The review queue is
["needs-review"].Tags the transaction must have at least one of (OR).
Max 500.
Opaque pagination cursor from a previous response. Only valid with
sort_by=date.date, amount, or provider_name.desc or asc.Comma-separated fields or aliases (
minimal, core, category, timestamps). See Conventions. id is always included.When
true, return only {"count": N} for the given filters — no rows, no pagination. cursor, limit, sort_by, sort_order, and fields are ignored. Use this to size a result set or compare counts across date ranges or categories before paginating. Replaces the retired count_transactions tool.Example input
Example output
Example output
Counting matches: query_transactions(count_only=true)
There is no separate count_transactions tool. To get just a count for a given set of filters, pass count_only: true to query_transactions with the same filters you’d otherwise use. The response is {"count": N} with no rows, no pagination, and no cursor — cursor, limit, sort_by, sort_order, and fields are ignored. Agents use this as a cheap pre-flight to decide whether to paginate or narrow filters.
Scope: Read
Mirrors: GET /api/v1/transactions/count
Example input
Example output
transaction_summary
Returns aggregated transaction totals grouped by category, month, week, day, or category × month. Replaces the need to paginate through every transaction for spending analysis. Amounts follow the Plaid convention — positive = money out. Scope: Read Mirrors:GET /api/v1/transactions/summary
Parameters
One of
category, month, week, day, category_month.Defaults to 30 days ago.
Defaults to today.
Filter by account.
Filter by family member (attribution-aware).
Filter by primary category before aggregating.
Include pending transactions.
Example input
Example output
Example output
list_annotations
Returns the activity timeline for a single transaction: comments, tag adds/removes, rule applications, and category sets. Ordered bycreated_at ascending. Use this to reconstruct “what happened to this transaction and when” before making further changes.
Each row carries a generic kind plus an action for the specific event, so you can branch on the action without parsing the kind string:
kind | action values | Notes |
|---|---|---|
comment | (omitted) | Free-form comment. payload.content carries the body. |
rule | applied | A transaction rule fired. payload.rule_name and rule_id are populated. |
tag | added / removed | Tag attached to or detached from the transaction. tag_id and payload.slug are populated. |
category | set | Category was set (manual override or via rule). |
Parameters
UUID or short ID of the transaction.
Optional kind filter. Any of
comment, rule, tag, category. Empty (default) returns the full timeline. Pass ['comment'] for the comment-only view (replaces the deprecated list_transaction_comments); pass ['tag'] for both add and remove tag events; pass ['comment','tag','category'] to skip rule-application churn.Only the generic kinds above are accepted at the MCP boundary — the underlying DB-level values (tag_added, tag_removed, rule_applied, category_set) will be rejected with an invalid kind error.Example input
list_transaction_comments):
Example output
Example output
kind carries the generic event family (comment, rule, tag, category) and action carries the specific event (added, removed, set, applied). Comment rows omit action because there is only one event. Actor identity is split across actor_type (user / agent / system), actor_name, and optional actor_id. When a write tool passed a session_id, it’s echoed here so you can group events by session. Rule applications set rule_id; tag events set tag_id.