Сервер MCP, предоставляющий Akahu (открытый банкинг в Новой Зеландии) данные для LLM-агентов, таких как Claude. Позволяет агенту просматривать ваши банковские счета, проверять инвестиционные портфели и получать транзакции для анализа.
Локальный кэш SQLite (cache.db) хранит транзакции примерно за последние 90 дней на диске и обновляется инкрементально. Время жизни кэша (TTL) составляет 24 часа, что соответствует частоте обновления данных в Akahu Personal (раз в сутки); агенты могут передать force=True в любой инструмент, чтобы обойти это ограничение.
list_accounts(force=False) — банковские/депозитные счета с балансами. Sharesight исключен.
get_share_holdings(force=False) — портфель Sharesight: общая стоимость, детализация (доходность / капитал / валюта / дивиденды) и строки по каждому активу.
list_transactions(account, start=None, end=None, limit=100, force=False) — транзакции по одному счету из локального кэша, с предварительным обновлением из Akahu, если кэш старше 24 часов. account сопоставляется по ID или нечеткому совпадению подстроки имени.
Related MCP server: financy
Установите uv, если у вас его еще нет.
Настройте Akahu Personal App — это бесплатные приложения для одного пользователя, которые вы создаете для своей учетной записи Akahu. Вы получите app_token (ID личного приложения) и user_token для себя.
Создайте файл .env в корне проекта:
AKAHU_USER_TOKEN=user_token_xxx
AKAHU_APP_TOKEN=app_token_xxxuv sync для установки зависимостей.
Проверка работоспособности: uv run python -m akahu_mcp.sync — должны отобразиться ваши счета и загрузиться транзакции для первого из них.
claude mcp add akahu --scope user -- uv --directory /absolute/path/to/akahu-mcp run akahu-mcpДобавьте в ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) или аналогичный файл на вашей платформе:
{
"mcpServers": {
"akahu": {
"command": "uv",
"args": ["--directory", "/absolute/path/to/akahu-mcp", "run", "akahu-mcp"]
}
}
}Если ваш хост не может найти uv в PATH, замените "uv" на абсолютный путь, полученный командой which uv.
Создано и протестировано с использованием Akahu Personal Apps, которые обновляют данные на стороне сервера только раз в день — отсюда и TTL кэша в 24 часа. Те же конечные точки существуют в коммерческих планах, но там может иметь смысл сократить TTL.
В папке legacy/ содержатся два оригинальных скрипта (akahu.py, list_accounts.py), из которых вырос этот проект. Они по-прежнему работают автономно — установите их зависимости с помощью uv sync --group legacy, затем используйте uv run --group legacy python legacy/list_accounts.py.
List the user's bank/depository accounts (excludes Sharesight, which has its own tool). Cached for 24h; pass force=True to refresh from Akahu.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses caching (24h) and refresh mechanism (force=True), which is good for a read tool. It does not mention auth requirements or error cases, but the core behavior is transparent.
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, front-loaded with purpose, then additional details. Every word earns its place, no fluff.
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 the output schema exists (context signal), the description needn't explain return values. It covers purpose, scope, caching, and parameter usage. For a list tool with one optional parameter, this is complete.
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 input schema has 0% parameter description coverage, so the description compensates by explaining the 'force' parameter: pass force=True to refresh from Akahu. This provides necessary semantics beyond the schema.
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 lists 'bank/depository accounts' and explicitly excludes Sharesight, which is handled by a sibling tool. The verb 'list' and specific resource make the purpose 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?
The description tells when to use (for bank/depository accounts) and excludes Sharesight. It also explains caching behavior and how to refresh with force=True. It could explicitly mention alternatives (e.g., get_share_holdings for Sharesight) but the exclusion is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List transactions for a bank account, served from a local cache that keeps the last ~90 days. The cache is refreshed at most once per 24h (Akahu Personal only refreshes upstream daily); pass force=True to bypass the TTL.
Args: account: account id or fuzzy substring match against account name start: ISO date (YYYY-MM-DD), inclusive lower bound on transaction date end: ISO date (YYYY-MM-DD), inclusive upper bound limit: max rows to return (default 100, newest first) force: bypass the 24h cache TTL
| Name | Required | Description | Default |
|---|---|---|---|
| account | Yes | ||
| start | No | ||
| end | No | ||
| limit | No | ||
| force | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses caching (last ~90 days, 24h refresh), force parameter effect, and default limit order. It does not cover error handling or edge cases, but the output schema exists for return format.
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?
The description is structured with the main sentence followed by bullet-like Args. It is slightly verbose but each sentence contributes essential information. The purpose 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 the 5 parameters and output schema, the description covers caching, date range, limit, and force flag. It lacks mention of error handling or account not found, but is largely complete for a list 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 0%, but the description thoroughly explains all five parameters: account (fuzzy match), start/end (ISO dates), limit (max rows, default 100), force (bypass cache). This adds substantial value beyond the bare schema.
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 action and resource: 'List transactions for a bank account'. The sibling tools (get_share_holdings, list_accounts) deal with distinct resources, eliminating confusion.
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 explains caching behavior and the force parameter to bypass TTL, giving context on when to use this tool. It does not explicitly exclude alternative tools, but the resource difference makes it clear.
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.1.0get_share_holdingslist_accountslist_transactionsScored across 3 tools
Each tool targets a distinct area: share holdings, bank accounts, and transactions. There is no overlap in purpose.
All tool names follow a consistent verb_noun pattern: get_share_holdings, list_accounts, list_transactions.
3 tools cover the core read-only functionalities for personal finance. While limited, it is appropriate for the server's scope.
The set covers accounts, transactions, and investments, but lacks operations like getting a single account detail or investment transactions, leaving some gaps.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Personal finance for AI agents — onboard, import statements, categorize & budget over MCP.
Hosted MCP server for live public-data APIs and Skills for AI agents.
Personal finance, bank account, and shared memory connector for Claude, ChatGPT, Gemini Spark & more
