Akahu(뉴질랜드 오픈 뱅킹) 데이터를 Claude와 같은 LLM 에이전트에 노출하는 MCP 서버입니다. 에이전트가 사용자의 은행 계좌 목록을 확인하고, 투자 자산을 검토하며, 분석을 위해 거래 내역을 가져올 수 있도록 합니다.
로컬 SQLite 캐시(cache.db)는 최근 약 90일간의 거래 내역을 디스크에 보관하며 점진적으로 새로 고칩니다. 캐시 TTL은 Akahu Personal의 일일 업스트림 새로 고침 주기에 맞춰 24시간으로 설정되어 있습니다. 에이전트는 모든 도구에서 force=True를 전달하여 이를 우회할 수 있습니다.
list_accounts(force=False) — 잔액이 포함된 은행/예금 계좌 목록입니다. Sharesight는 제외됩니다.
get_share_holdings(force=False) — Sharesight 포트폴리오: 총 가치, 세부 내역(수익/자본/통화/배당금) 및 보유 항목별 행을 제공합니다.
list_transactions(account, start=None, end=None, limit=100, force=False) — 로컬 캐시에서 특정 계좌의 거래 내역을 가져옵니다. 캐시가 24시간보다 오래된 경우 Akahu에서 먼저 새로 고칩니다. 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"]
}
}
}호스트가 PATH에서 uv를 찾을 수 없는 경우, "uv"를 which uv 명령어로 확인한 절대 경로로 바꾸세요.
Akahu Personal Apps를 대상으로 구축 및 테스트되었으며, 이 앱은 업스트림 데이터를 하루에 한 번만 새로 고치므로 24시간 캐시 TTL을 사용합니다. 상용 플랜에서도 동일한 엔드포인트가 존재하지만, 상용 플랜의 경우 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
