This server provides read-only access to banking data via the Akahu API, offering three tools:
list_accounts – List all bank accounts with current and available balances.
bank_get_balance – Get the current and available balance for a specific account by its Akahu account ID, with an optional refresh flag to force a fresh pull from the bank.
bank_get_transactions – Fetch settled (posted) transactions for a specific account by its Akahu account ID, with optional ISO 8601 date range filtering (start is exclusive, end is inclusive).
Note: The server schema only exposes these three tools. Additional tools like
bank_get_all_transactions,bank_get_pending_transactions, andbank_get_connection_healthare described in the documentation but are not available in this server instance.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@akahu-mcp show me my account balances"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server exposing the Akahu banking API as tools - list accounts, get a balance, get settled and pending transactions, check connection health.
Every tool is read-only. This server backs an Akahu personal app, which by definition
cannot make payments or subscribe to webhooks - the only side effect it can produce is asking
Akahu to refresh from the bank, behind an explicit refresh flag.
list_accounts list every account Akahu has
access to, with balance, credit limit, status and last-refreshed timestamps.
bank_get_balance, bank_get_transactions look up a specific account by its
Akahu account ID.
bank_get_all_transactions - settled transactions across every account at once, for finding
a payment without knowing which account it went through.
bank_get_pending_transactions - money committed but not yet posted, which no balance
reflects yet.
bank_get_connection_health - whether each bank connection is still active, and how stale
its data is.
Related MCP server: akahu-mcp
git clone git@github.com:adrianparker/akahu-mcp.git
cd akahu-mcp
npm install
cp .env.example .envFill in .env:
NODE_ENV=app
AKAHU_APP_TOKEN=app_token_...
AKAHU_USER_TOKEN=user_token_...Get your Akahu tokens from developers.akahu.nz. Use
npm run cli -- list-accounts to find the account IDs to pass to balance/transactions.
npm startRuns src/index.js on stdio and waits for JSON-RPC input - that's normal, Ctrl+C to stop. For
an interactive check of the tool calls before wiring it into Claude, use the official
inspector:
npx @modelcontextprotocol/inspector npm startWire it into Claude by adding an entry to your MCP client config (e.g.
claude_desktop_config.json, or a project .mcp.json):
{
"mcpServers": {
"akahu-mcp": {
"command": "node",
"args": ["/absolute/path/to/akahu-mcp/src/index.js"]
}
}
}src/index.js loads .env itself (resolved relative to its own file, not the launching
process's cwd), so you don't need to pass tokens through the MCP client config.
list_accounts - { refresh?: boolean }. Every account Akahu has access to, including
balance (current, available, limit, overdrawn, currency), status, attributes and when Akahu
last refreshed each one.
bank_get_balance - { account: string, refresh?: boolean }. account is the Akahu
account ID (see list_accounts). refresh: true asks Akahu to refresh from the bank
first, then polls until the refresh lands (up to 30s) before reading the balance.
bank_get_transactions - { account: string, start?: string, end?: string }. account is
the Akahu account ID. Dates are ISO 8601; start is exclusive, end is inclusive (Akahu's
own semantics). Omit both for everything the app can access. Paginates internally, so you
always get the full result in one call.
bank_get_all_transactions - { start?: string, end?: string }. The same settled
transactions, across every account in one sweep. Each row carries its account ID, and the
response includes an accounts lookup mapping those IDs to a bank and account name.
bank_get_pending_transactions - { account?: string }. Pending (unsettled) transactions;
omit account for every account. Pending rows are not stable - date, description and amount
can all change before they settle, and they carry no ID. Payments made through Akahu itself
never appear here.
bank_get_connection_health - no arguments. Per bank connection: whether every account on it
is still ACTIVE, and how many hours since Akahu last pulled fresh balance and transaction
data. Most stale first.
Transactions are returned enriched where Akahu has the data: merchant, category
(NZFCC name plus its higher-level group), and meta with the particulars, code,
reference, otherAccount and cardSuffix a NZ bank carries on a direct debit or credit.
Both transaction tools paginate internally and return a truncated flag. If it is true
the date range was too wide to return in full (20 pages per account, 50 across all
accounts) and transactions are missing — narrow the range and call again.
For a human, not an MCP client - same data, rendered as a table:
npm run cli -- list-accounts
npm run cli -- balance acc_...
npm run cli -- balance acc_... --refresh
npm run cli -- transactions acc_... --start 2026-01-01 --end 2026-02-01
npm run cli -- all-transactions --start 2026-01-01 --end 2026-02-01
npm run cli -- pending
npm run cli -- pending acc_...
npm run cli -- connection-healthOr use the akahu bin directly once installed globally / linked, so you don't need the
npm run cli -- prefix:
akahu balance acc_...To install globally from this checkout (picks up package.json's bin entry):
npm install -g .For development, npm link instead - it symlinks the global akahu bin back to this
checkout, so edits to src/cli.js take effect immediately without reinstalling:
npm linkEither way, .env is resolved relative to the current working directory (via dotenv.config()
in src/cli.js), not the checkout - so run akahu from a directory containing a filled-in
.env, or export AKAHU_APP_TOKEN/AKAHU_USER_TOKEN in your shell. To remove a global
install or link later: npm uninstall -g akahu-mcp (works for both).
npm test
npm run test:watchnpm run coverage100% coverage is the bar for this project - src/index.js and src/cli.js carry a c8 ignore
around their if (import.meta.url === ...) entrypoint guard, since that only runs when the bin
is actually executed, not under unit tests.
npm run lintAGPL-3.0-only — see LICENSE.
Get the current and available balance for one bank account by its Akahu account ID. Use list_accounts to find the ID.
| Name | Required | Description | Default |
|---|---|---|---|
| account | Yes | The Akahu account ID to fetch. | |
| refresh | No | Ask Akahu to refresh from the bank before reading the balance. Adds ~10 seconds. Defaults to false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It accurately implies a read-only operation (getting balance) and specifies it returns both current and available balance. However, it does not mention potential side effects of the refresh parameter or any rate limits, though the refresh behavior is covered in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no unnecessary words. The core function is front-loaded, and the prerequisite instruction is concise. This is an example of efficient specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple balance lookup tool with two well-documented parameters, the description is sufficient. It names the exact resource and necessary input. The lack of output schema is not problematic for such a straightforward operation, and the relationship to list_accounts is clarified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage of parameter descriptions, so the baseline is 3. The description adds extra value by advising how to obtain the account ID ('Use list_accounts to find the ID'), which directly helps the agent understand the relationship between parameters and sibling tools, exceeding the schema's generic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the specific resource 'current and available balance' for one bank account, identified by Akahu account ID. It distinguishes itself from siblings like bank_get_transactions (which would fetch transactions) and list_accounts (which lists accounts), making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the user to use list_accounts to find the account ID, which is a clear prerequisite. It does not mention when not to use it or alternative tools for similar purposes, but it provides a direct contextual hint for the primary workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get settled (posted) transactions for one bank account by its Akahu account ID, optionally within a date range. Dates are ISO 8601 (e.g. "2026-06-01"). start is exclusive, end is inclusive, matching Akahu semantics. Omit both to get all transactions the app can access (up to its historical access window).
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ISO 8601 date/time, inclusive upper bound. Omit for the latest available. | |
| start | No | ISO 8601 date/time, exclusive lower bound. Omit for the earliest available. | |
| account | Yes | The Akahu account ID to fetch. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that only settled/posted transactions are returned, explains the exclusive/inclusive date boundaries, and notes the historical access window when both dates are omitted. This is substantial behavioral context beyond a naive 'get transactions' statement, though it doesn't cover pagination or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first identifies the tool's core function, second clarifies date format, third explains boundary semantics and omission behavior. Every sentence adds value, no fluff, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the essential operational details: settled transactions, date range rules, and fallback when dates are omitted. It doesn't describe the return shape (e.g., transaction object fields), but the core use cases are sufficiently addressed for a simple fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning by clarifying that 'start' is exclusive, 'end' is inclusive, and omitting both returns all accessible transactions. This goes beyond the schema's generic ISO 8601 descriptions, directly aiding parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets settled transactions for one bank account by Akahu account ID, with optional date range. This specific verb+resource+scope distinguishes it from siblings like bank_get_balance (balance) and list_accounts (account listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use: fetching settled transactions for a specific account, with date range semantics explicitly defined (exclusive start, inclusive end). It doesn't explicitly name alternatives or exclusions, but the sibling differentiation is implied by the tool's purpose, so a small gap remains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every bank account this server has access to via Akahu, with their current and available balance. Unrestricted - not limited to a specific allowlist. Takes no arguments.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the tool lists every accessible account and returns balances, but it does not mention potential volume, pagination, or authentication requirements. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core purpose. The extra clarification about being unrestricted is valuable, and 'Takes no arguments' is necessary. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains what is returned (current and available balance) and the scope (every account). It omits details like account identifiers or ordering, but for a simple listing tool this is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the description explicitly states 'Takes no arguments.' This adds a small but useful clarification beyond the empty schema, which already implies no parameters. Baseline for no-param tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists all bank accounts accessible via Akahu with current and available balances. This distinguishes it from sibling tools like bank_get_balance or bank_get_transactions, which target specific balance or transaction details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes the tool is 'Unrestricted - not limited to a specific allowlist', which implies it is the broad listing tool, but it does not explicitly mention when to use it over alternatives or when not to use it. Guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0bank_get_balancebank_get_transactionslist_accountsScored across 3 tools
Each tool serves a distinct purpose: listing accounts, fetching a single account's balance, and fetching a single account's transactions. No overlap or ambiguity between them.
Tool names follow a mostly consistent snake_case pattern with verb-noun structure, but two use the 'bank_get_' prefix while 'list_accounts' deviates slightly. The inconsistency is minor and does not hinder understanding.
Three tools is an appropriate size for a banking read-only integration, covering the essential operations without unnecessary bulk. Each tool earns its place.
The tool set covers the core read-only banking needs: account listing with balances and transaction retrieval. Minor gaps exist (e.g., no direct account details endpoint, no cross-account transaction aggregation), but these are not critical for the apparent purpose.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
MCP server for Modern Treasury — payment orders, transactions, counterparties and ledgers.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for Codat — companies, connections, invoices, bills and financial statements.
