de en es ja ko ru zh

open-banking-io MCP Server

Name: open-banking-io MCP Server
Author: open-banking-io

by open-banking-io

Overview Schema Source Related Servers Discussions Admin

Python

Remote

open-banking.io MCP-сервер

Тонкий только для чтения сервер Model Context Protocol для PSD2 API сервиса open-banking.io. Он позволяет ИИ-агентам (Claude Desktop, Cursor, любому MCP-клиенту) отвечать на вопросы вроде «Какой у меня баланс?» и «Дай сводку транзакций за прошлый месяц» по вашим собственным банковским счетам.

Он оборачивает официальный Python SDK open-banking-io и наследует его свойство zero-knowledge: сервис всегда возвращает только шифротекст, а каждое чувствительное поле (IBAN, имя владельца, суммы, контрагенты) расшифровывается в процессе работы с помощью вашего выгруженного закрытого ключа. Никакие открытые данные никогда не касаются третьей стороны — в том числе LLM видит только то, что ваш MCP-клиент отправляет ей.

Инструменты

Инструмент	Аргументы	Описание
`list_accounts`	—	банковские счета: банк, страна, IBAN, владелец, отображаемое имя, валюта, остатки, флаг `needs_reconnect`
`get_balances`	`account_id`	Остатки ISO 20022 для одного счёта (`ITBD` = проведённые, `ITAV` = доступные)
`get_transactions`	`account_id`, `date_from?`, `date_to?`, `limit?` (default 50, max 500), `offset?`	Строки выписки, новые первыми, с контрагентом и деталями перевода
`list_connections`	—	Подключения к банкам и согласия: статус, `valid_until`, `last_synced_at`, количество счетов

Все инструменты — только для чтения. Намеренно отсутствуют инструменты синхронизации, инициации платежей или управления разрешениями — см. Ограничения.

Related MCP server: saldo-mcp

Конфигурация

Переменная окружения	Обязательность	Описание
`OBI_CREDENTIALS`	предпочтительно	Путь к (или встроенный JSON) комплекту учётных данных, экспортируемому из приложения open-banking.io — содержит `apiBaseUrl`, `apiKey` и закрытый ключ шифрования
`OBI_API_KEY`	альтернатива	API-ключ, если вы не используете комплект
`OBI_PRIVATE_KEY`	альтернатива	Закрытый ключ Base64 PKCS#8 EC (SECP256R1), соответствующий `OBI_API_KEY`
`OBI_BASE_URL`	с альтернативным способом	Базовый URL API (поле `apiBaseUrl` из комплекта), обязателен при использовании раздельных переменных окружения

Экспортируйте учётные данные в приложении → Settings → Credentials, чтобы получить файл с комплектом.

Claude Desktop

claude_desktop_config.json (Claude → Settings → Developer → Edit Config):

{
  "mcpServers": {
    "open-banking-io": {
      "command": "uvx",
      "args": [
        "--from", "git+https://github.com/open-banking-io/mcp-server.git",
        "obi-mcp"
      ],
      "env": {
        "OBI_CREDENTIALS": "/absolute/path/to/credentials.json"
      }
    }
  }
}

Cursor

.cursor/mcp.json:

{
  "mcpServers": {
    "open-banking-io": {
      "command": "uvx",
      "args": [
        "--from", "git+https://github.com/open-banking-io/mcp-server.git",
        "obi-mcp"
      ],
      "env": {
        "OBI_CREDENTIALS": "/absolute/path/to/credentials.json"
      }
    }
  }
}

Требуется uv (curl -LsSf https://astral.sh/uv/install.sh | sh). После публикации на PyPI аргументом --from git+… можно будет убрать.

Локальный запуск / из исходного кода

git clone https://github.com/open-banking-io/mcp-server.git
cd mcp-server
uv venv && uv pip install -e '.[dev]' --python .venv/bin/python
OBI_CREDENTIALS=/path/to/credentials.json .venv/bin/obi-mcp   # speaks MCP over stdio
.venv/bin/python tests/smoke.py                               # network-free smoke test
uv run --python .venv/bin/python pytest -q                    # full test suite

Примеры вопросов для вашего агента

«Покажи проведённый остаток по каждому счёту.»
«Сколько я потратил на продукты в июле?» (get_transactions + группировка)
«Какие банковские подключения скоро истекают?» (list_connections)

Заметки по проектированию

Только для чтения по построению. Доступны только методы get_* из SDK. sync/sync_all в SDK есть, но намеренно не предлагаются; агенты не могут переводить деньги или изменять разрешения через этот сервер.
Точные деньги. Суммы возвращаются как точные десятичные строки ("1234.56"), никогда не как числа с плавающей точкой.
Понятные ошибки. Отсутствующие учётные данные, неверные даты, неизвестные идентификаторы счетов и ошибки вышестоящего HTTP-сервиса превращаются в понятные ошибки инструментов (например, при промахе выводится список допустимых идентификаторов счетов; неверной дате).
Бережёт контекст. get_transactions по умолчанию берёт 50 записей и ограничивает их до 500, чтобы не перегружать контекстное окно агента; используйте offset для постраничной навигации.

Ограничения (честный список)

Нет sync из SDK (нет инструментов записи, инициации платежей, создания/обновления разрешений). Обновление разрешений всегда происходит в приложении open-banking.io (PSD2 SCA).
Нет инструмента каталога банков/организаций: API, которое используется (в clients SDK v1.0.0) не предоставляет публичного эндпоинта поиска ASPSP — TODO, если/когда такой появится.
Пакет пока не опубликован на PyPI — устанавливайте через uvx --from git+… (см. выше) или из исходников. Публикация на PyPI как open-banking-io-mcp планируется.
Минимизация данных — ваша ответственность: транзакции включают контрагентов и текст платежа; подключайте этот сервер только к доверенным MCP-клиентам и предпочитайте локальные MCP-клиенты (Claude Desktop / Cursor) облачным из соображений приватности.

Обёрнутая часть API

Вызов SDK	HTTP (за вызовом SDK)
`get_accounts()`	`GET {apiBaseUrl}/api/accounts`
`get_transactions(id, from, to, limit, offset)`	`GET {apiBaseUrl}/api/accounts/{id}/transactions`
`get_connections()`	`GET {apiBaseUrl}/api/connections`

Авторизация: заголовок X-Api-Key. Ответы содержат zero-knowledge конверты (ECDH P-256 → HKDF-SHA256 → AES-256-GCM), расшифровываемые локально SDK. Полный формат передачи данных: clients repo · THREAT_MODEL.md.

Лицензия

MIT — так же, как и у репозиториев SDK clients.

Available Tools

4 tools

get_balancesA

Get the balances (booked, available, ...) of one account.

type is the ISO 20022 balance code: ITBD = booked (interim), ITAV = available. account_id comes from list_accounts.

ParametersJSON Schema

Name	Required	Description	Default
`account_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

No annotations are provided, so the description must carry the behavioral disclosure burden. It explains that the tool returns multiple balance types and defines the type codes. It does not explicitly state that the operation is read-only, but that is implicit and acceptable for a get operation. It adds useful context beyond the schema, such as the source of account_id.

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

Conciseness5/5

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

The description is succinct and front-loaded, using two sentences and a brief code block for the type codes. Every sentence adds value with no redundant text.

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?

Given that an output schema exists (not shown in detail), we don't need description of return values. The tool is simple (one required parameter) and the description covers the essential semantics, including the meaning of type codes. It is complete for a straightforward get-balances endpoint.

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

Parameters3/5

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

Schema coverage is 0%, so the description must compensate. It does explain account_id (source from list_accounts) and defines the type parameter even though 'type' is not present in the provided schema. This discrepancy between description and schema introduces potential confusion about whether the type parameter is actually accepted, lowering the score.

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 clearly states 'Get the balances (booked, available, ...) of one account' which uses a specific verb and resource, and distinguishes it from sibling tools like list_accounts, get_transactions, and list_connections. The mention of ISO 20022 balance codes adds specificity.

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 provides a clear prerequisite: 'account_id comes from list_accounts', guiding the agent to obtain the identifier from a specific prior step. It also explains the meaning of the optional type parameter, though it does not explicitly state when to use this tool versus alternatives, which is fairly obvious given the sibling set.

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

get_transactionsA

Get statement transactions for one account, newest first.

Args: account_id: Account id from list_accounts. date_from: Optional inclusive start date, ISO YYYY-MM-DD. date_to: Optional inclusive end date, ISO YYYY-MM-DD. limit: Page size (default 50, max 500 — keep small to protect context). offset: Skip offset items before the page (for pagination).

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`offset`	No
`date_to`	No
`date_from`	No
`account_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does well: it discloses newest-first ordering, inclusive date semantics, page size default and maximum, offset-based pagination, and a practical context-window warning ('keep small to protect context'). This goes well beyond 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.

Conciseness5/5

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

The first line is a crisp summary, and the Args section is tightly formatted with no filler. Every sentence earns its place by conveying scope, defaults, limits, or safety guidance.

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?

Given that an output schema exists, return fields need not be restated. The description covers prerequisites, date range behavior, pagination, and resource-protection guidance, leaving no meaningful gaps for a read-only transaction listing tool.

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

Parameters5/5

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

Schema description coverage is 0%, but the description compensates fully by explaining every parameter: account_id's source, date_from/date_to as optional inclusive ISO dates, limit's default/max/contextual caution, and offset's pagination role. This adds meaning beyond the raw schema types and defaults.

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?

Description opens with a specific verb+resource: 'Get statement transactions for one account, newest first.' It clearly identifies that this tool retrieves transactions for a single account and distinguishes itself from siblings like list_accounts, get_balances, and list_connections.

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?

Provides clear usage context: one account, optional inclusive date range, and pagination. It also points to the prerequisite 'Account id from list_accounts.' While it does not explicitly name alternative tools or exclusions, the purpose and sibling set make the intended use clear.

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

list_accountsA

List the user's bank accounts with balances, IBAN, owner and bank name.

Sensitive fields are decrypted in-process from the zero-knowledge envelopes. Use an account's id for get_balances / get_transactions.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description must carry the behavioral disclosure burden. It does so by revealing that 'Sensitive fields are decrypted in-process from the zero-knowledge envelopes,' which is non-obvious and important context for the agent. It does not mention every possible behavioral trait, but it covers the most relevant security-sensitive aspect.

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

Conciseness5/5

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

The description is three concise sentences: the first states the purpose and returned fields, the second provides essential security context, and the third gives actionable downstream usage. Every sentence earns its place with no redundancy.

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?

Given the tool has no parameters, an output schema is present, and the description covers purpose, fields, security behavior, and how to use the result with sibling tools, it is complete enough for an agent to select and invoke it correctly. No significant gaps remain.

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?

The input schema is empty with zero parameters, so the description does not need to explain parameter semantics. Per the zero-parameter baseline, a score of 4 is appropriate since there is nothing ambiguous to clarify.

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 starts with a specific verb and resource: 'List the user's bank accounts with balances, IBAN, owner and bank name.' It clearly defines the tool's scope and differentiates it from siblings by noting that account IDs should be used with get_balances/get_transactions.

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 tells the agent how to use the output: 'Use an account's ``id`` for get_balances / get_transactions.' This gives downstream usage context, though it does not explicitly contrast with list_connections or state when not to use this tool.

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

list_connectionsA

List the user's bank connections (consents): status, validity, last sync.

A connection with status expired / needs_reconnect means fresh data requires re-consent in the open-banking.io app — this server cannot restore consent.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are present, so the description carries the full burden. It discloses a key behavioral nuance: expired/needs_reconnect connections require re-consent elsewhere and that this server cannot restore consent. This exceeds a bare 'list' complete with an important limitation, though it doesn't cover all potential behaviors (e.g., pagination, filtering).

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

Conciseness5/5

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

Two sentences, both essential. The first defines the resource and content, the second adds critical status-related caveat. No redundancy or filler.

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 simple no-parameter list tool with an output schema, the description provides enough context: purpose, key fields, and an important behavioral constraint. It might mention pagination or ordering, but these are likely in the output schema, so the description is complete enough.

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?

The tool has zero parameters, so the default baseline is 4. The description adds value by specifying the fields returned even though no parameters exist, making the tool's behavior clear without parameter explanations.

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?

Uses a specific verb+resource ('List the user's bank connections (consents)') and enumerates the data returned (status, validity, last sync). Clearly distinguishes from sibling tools focused on accounts, balances, and transactions.

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?

The description implies usage via the domain (connections vs. accounts) and explains the implication of expired status, but it does not explicitly state when to prefer this tool over alternatives or provide exclusions. Usage context is implied rather than directly stated.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.1.0Aug 20, 2026
- First observedget_balances
- First observedget_transactions
- First observedlist_accounts
- First observedlist_connections

Deploy Server

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

TDQS

A4.6/5.0

Scored 2026-08-20 13:30 across 4 tools

Disambiguation5/5

Each tool targets a distinct resource: accounts, balances, transactions, and connections. No overlap exists, and the descriptions reinforce clear boundaries.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (list_accounts, get_balances, get_transactions, list_connections), making the API intuitive and predictable.

Tool Count5/5

With exactly 4 tools, the server is well-scoped for a read-only banking API, covering the core data needs without unnecessary bloat or sparsity.

Completeness5/5

The tool set covers the full read lifecycle: listing accounts, retrieving balances and transactions, and managing connection status. No obvious gaps exist for the stated purpose.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

thoughtsOAuth
ai.thoughtbox.api
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Cloud Storage Finance
2
BankBridgeOAuth
money.bankbridge
Read-only banking and personal finance for AI agents: accounts, transactions, spending, budgets.
Finance Databases
2
ClarityTrackOAuth
ai.claritytrack
Ask your AI about your own accounts, debts, budgets and goals. OAuth sign-in, read-only by default.
Finance Search Security
1
wimmOAuth
my.wimm
Personal finance for AI agents — onboard, import statements, categorize & budget over MCP.
Finance Data Platforms
2

Related MCP Servers

Account and Transaction MCP
Finance Search Developer Tools
ag2-mcp-servers
F
license
Not graded
quality
D
maintenance
An MCP Server that provides a conversational interface to the UK Open Banking account information API, allowing agents to interact with bank account data through natural language commands.
Updated a year ago (2025-07-16 14:20 UTC)
-
saldo-mcp
Finance Security
pixby
A
license
Not graded
quality
D
maintenance
A read-only MCP server that securely connects Swedish/Nordic bank accounts to AI assistants, keeping all financial data local and encrypted.
Updated 3 months ago (2026-07-21 22:49 UTC)
12 npm
MIT
TurkishBankMCP
Finance
OnurByte
A
license
B
quality
B
maintenance
A read-only MCP server that exposes Turkish open banking data (accounts, balances, transactions, cash flow, and cards) to AI agents via the ÖHVPS 2.0.0 standard.
Updated 2 months ago (2026-08-31 15:32 UTC)
5
MIT
BankMCP
Finance Security
noskillish
A
license
A
quality
A
maintenance
Self-hosted MCP server that securely connects your bank accounts via Enable Banking, offering read-only access to balances and transactions for AI assistants.
Updated 22 days ago (2026-09-28 16:37 UTC)
12
144 npm
288
MIT