vokse

List transactions

list_transactions

Read-only

List transactions, newest first. Filters: accountId, categoryId, payeeId, dateFrom/dateTo (YYYY-MM-DD), search (memo, payee names and aliases, receipt text), amount range, tagIds (any-of), flagIds / hasFlag (colour flags; names via list_transaction_flags), hasReceipt, needsReview, uncategorized. uncategorized: true = every row with no category that can take one (any sign, any account; transfer legs, system rows and split parents excluded), independent of needsReview. needsReview is a small subset: to find everything that still needs a category use uncategorized: true. Paginated: pass nextCursor back as cursor until it is null; limit up to 100. Rows are compact by default (id, date, amountCents, currency, accountId, payeeName; payeeId, categoryId, memo, flagId, tagIds, splits, transferGroupId, suggestedCategoryId / suggestionConfidence / suggestionSource only when set, status only when not cleared, needsReview only when true: a missing categoryId means uncategorised). Compact rows carry everything needed to categorise; fields: "full" (every column) is for API clients that need the rest, never a reason to re-fetch a page.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Page size. Defaults to 20.
`cursor`	No	nextCursor from the previous page.
`dateTo`	No	Up to this day, YYYY-MM-DD (inclusive).
`fields`	No	compact (default) or full, every column, for API clients.
`search`	No	Text in the memo, payee names and aliases, or receipt text.
`status`	No	Only this status.
`tagIds`	No	Rows carrying any of these tags, ids from list_tags.
`flagIds`	No	Rows with any of these flags, ids from list_transaction_flags.
`hasFlag`	No	true: only rows with a colour flag.
`payeeId`	No	Only this payee.
`dateFrom`	No	From this day, YYYY-MM-DD (inclusive).
`accountId`	No	Only this account.
`categoryId`	No	Only this category.
`hasReceipt`	No	true: only rows with a receipt photo.
`householdId`	No	Household ULID to act on. Call list_households for the covered households; may be omitted only when the connection covers exactly one.
`needsReview`	No	Only rows that need review (true) or not (false).
`uncategorized`	No	true: every row that can still take a category.
`maxAmountCents`	No	Highest signed amount in cents, as a string; outflows are negative.
`minAmountCents`	No	Lowest signed amount in cents, as a string; outflows are negative.

Schema Changelog

Changes observed during successful MCP inspections.

Changed18 schema fields changedSep 14, 2026

addedInput schema / properties / accountId / description
```
Added value: +"Only this account."
```
addedInput schema / properties / categoryId / description
```
Added value: +"Only this category."
```

addedInput schema / properties / cursor / description

Added value: +"nextCursor from the previous page."

addedInput schema / properties / dateFrom / description

Added value: +"From this day, YYYY-MM-DD (inclusive)."

addedInput schema / properties / dateTo / description

Added value: +"Up to this day, YYYY-MM-DD (inclusive)."

addedInput schema / properties / fields / description

Added value: +"compact (default) or full, every column, for API clients."

addedInput schema / properties / flagIds / description

Added value: +"Rows with any of these flags, ids from list_transaction_flags."

addedInput schema / properties / hasFlag / description

Added value: +"true: only rows with a colour flag."

addedInput schema / properties / hasReceipt / description
```
Added value: +"true: only rows with a receipt photo."
```
addedInput schema / properties / limit / description
```
Added value: +"Page size. Defaults to 20."
```

addedInput schema / properties / maxAmountCents / description

Added value: +"Highest signed amount in cents, as a string; outflows are negative."

addedInput schema / properties / minAmountCents / description

Added value: +"Lowest signed amount in cents, as a string; outflows are negative."

addedInput schema / properties / needsReview / description

Added value: +"Only rows that need review (true) or not (false)."

addedInput schema / properties / payeeId / description
```
Added value: +"Only this payee."
```

addedInput schema / properties / search / description

Added value: +"Text in the memo, payee names and aliases, or receipt text."

addedInput schema / properties / status / description
```
Added value: +"Only this status."
```

addedInput schema / properties / tagIds / description

Added value: +"Rows carrying any of these tags, ids from list_tags."

addedInput schema / properties / uncategorized / description

Added value: +"true: every row that can still take a category."

First observedSep 13, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint/destructiveHint annotations, the description discloses rich behavior: newest-first ordering, pagination mechanics, conditional field presence in compact rows, the exact semantics of uncategorized (excluding transfer legs, system rows, split parents), and the relationship between needsReview and uncategorized. It even warns that re-fetching a page for full fields is never necessary.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well-structured: purpose first, then filters, then pagination, then return-row semantics. Every section adds value, though the filter enumeration partially duplicates what the schema already documents. It is long but earns its length by clarifying relationships the schema cannot express.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 19 parameters, no output schema, and no required fields, the description carries a heavy burden. It covers return format (compact vs full), conditional fields, pagination semantics, filter semantics for the trickiest parameters, and the distinction between uncategorized and needsReview. An agent can invoke this tool correctly without needing external information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful nuance beyond the schema: it explains uncategorized semantics in detail, clarifies that flagIds come from list_transaction_flags, specifies that search covers memo, payee names and aliases, and receipt text, and distinguishes needsReview as a small subset of uncategorized.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'List transactions, newest first.' It further clarifies scope by enumerating the many filter dimensions (accountId, categoryId, payeeId, date range, search, flags, etc.), which clearly distinguishes it from sibling tools like get_transaction (single transaction) and search (cross-entity search).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear operational context: pagination with nextCursor, limit up to 100, compact vs full field selection, and explicit guidance on when to use uncategorized:true versus needsReview. It does not explicitly name sibling alternatives like search or get_transaction, so it stops short of full when/when-not guidance, but the context is sufficiently clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All vokse tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?