Skip to main content
Glama
Sign In
nz-openbank-mcp

nz-openbank-mcp

by thatskiff33
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Get Transactions

txn_get_transactions
Read-only

Retrieve settled bank transactions with filters for account, date range, amount, and category, returning amounts, merchant, and category details for reconciliation or spending analysis.

Instructions

List settled transactions with optional filters.

Returns {"transactions": [...], "truncated": bool} where each entry has id, account_id, date (YYYY-MM-DD, NZ calendar day), description, amount (formatted in the account's currency, e.g. "-$12.50" or "-USD 9.99"), amount_raw (number rounded to cents; negative = debit), currency (ISO code, or None when the account's currency is unknown, in which case amount has no symbol, e.g. "-1,234.50"), type, merchant (str | None), category (str | None). truncated is true when the scan stopped at the 20-page cap before reaching the end of the range; narrow the dates and call again.

Input Schema

NameRequiredDescriptionDefault
limitNoMax items returned, 1 to 500 (default 100).
categoryNoExact category name (applied after fetching).
end_dateNoLatest NZ day as YYYY-MM-DD (inclusive), or an ISO 8601 timestamp passed to Akahu as an inclusive upper bound (UTC if it has no offset).
account_idNoScope to one account (sent to Akahu).
max_amountNoUpper bound on signed amount (applied after fetching).
min_amountNoLower bound on signed amount (applied after fetching; negatives are debits).
start_dateNoEarliest NZ day as YYYY-MM-DD (inclusive), or an ISO 8601 timestamp passed to Akahu as an exclusive lower bound (UTC if it has no offset).

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv0.1.6
    • changedInput schema / properties / account_id / description
      Previous value: -"Scope to one account (server-side filter)."New value: +"Scope to one account (sent to Akahu)."
    • changedInput schema / properties / category / description
      Previous value: -"Exact Category.name match (client-side filter)."New value: +"Exact category name (applied after fetching)."
    • changedInput schema / properties / end_date / description
      Previous value: -"ISO 8601 timestamp upper bound (server-side filter)."New value: +"Latest NZ day as YYYY-MM-DD (inclusive), or an ISO 8601\ntimestamp passed to Akahu as an inclusive upper bound (UTC if it\nhas no offset)."
    • changedInput schema / properties / limit / description
      Previous value: -"Max items returned (default 100)."New value: +"Max items returned, 1 to 500 (default 100)."
    • addedInput schema / properties / limit / maximum
      Added value: +500
    • addedInput schema / properties / limit / minimum
      Added value: +1
    • changedInput schema / properties / max_amount / description
      Previous value: -"Upper bound on signed amount (client-side)."New value: +"Upper bound on signed amount (applied after fetching)."
    • changedInput schema / properties / min_amount / description
      Previous value: -"Lower bound on signed amount (client-side; negatives are debits)."New value: +"Lower bound on signed amount (applied after fetching; negatives are debits)."
    • changedInput schema / properties / start_date / description
      Previous value: -"ISO 8601 timestamp lower bound (server-side filter)."New value: +"Earliest NZ day as YYYY-MM-DD (inclusive), or an ISO 8601\ntimestamp passed to Akahu as an exclusive lower bound (UTC if it\nhas no offset)."
  2. First observedv0.1.0

TDQS

A4/5.0
Behavior5/5

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

With only readOnlyHint=true in annotations, the description carries the behavioral load and does it well: exact return envelope, per-field semantics, the 20-page scan cap, and what truncated=true means plus the remedy. This is exactly the operational detail annotations cannot supply.

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 purpose is front-loaded in one line, then the return contract is packed into a single tight block. It is dense but nearly every clause conveys a distinct fact about format or edge cases; only the field enumeration borders on redundancy given an output schema exists.

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

Completeness4/5

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

For a 7-parameter read-only listing tool, an agent has everything needed to call it and interpret the result, including truncation handling. The per-field restatement is partly duplicative since an output schema is present, but the truncation and currency-unknown cases justify it.

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 baseline is 3; the description earns above that by clarifying signed-amount semantics (negative = debit), the account-currency formatting variants, and the NZ-calendar-day convention that underpins the date filters.

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

Purpose4/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 settled transactions") plus scope ("optional filters"). The word "settled" quietly distinguishes it from the pending-transaction siblings, though it never names them explicitly.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: "settled" excludes pending, and "narrow the dates and call again" gives recovery guidance for truncation. However, it never tells an agent when to prefer txn_search_transactions or txn_get_transactions_by_ids over this tool, so sibling routing is left to inference.

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

Deploy Server

Other Tools