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-Server

Ein schlanker, schreibgeschützter Model Context Protocol-Server für die open-banking.io PSD2-API. Er ermöglicht KI-Agenten (Claude Desktop, Cursor, beliebige MCP-Clients) Fragen wie „Wie hoch ist mein Kontostand?“ und „Fasse die Transaktionen des letzten Monats zusammen“ über Ihre eigenen Bankkonten zu beantworten.

Er kapselt das offizielle open-banking-io Python-SDK und erbt dessen Zero-Knowledge-Eigenschaft: Der Dienst gibt nur Chiffretext zurück, und jedes sensible Feld (IBAN, Kontoinhabername, Beträge, Gegenparteien) wird im Prozess mit Ihrem exportierten privaten Schlüssel entschlüsselt. Kein Klartext berührt jemals einen Dritten – auch das LLM sieht nur, was Ihr MCP-Client ihm sendet.

Werkzeuge

Werkzeug	Argumente	Beschreibung
`list_accounts`	—	Bankkonten: Bank, Land, IBAN, Inhaber, Anzeigename, Währung, Salden, `needs_reconnect`-Flag
`get_balances`	`account_id`	ISO-20022-Salden für ein Konto (`ITBD` = gebucht, `ITAV` = verfügbar)
`get_transactions`	`account_id`, `date_from?`, `date_to?`, `limit?` (Standard 50, max. 500), `offset?`	Kontoauszüge, neueste zuerst, mit Gegenpartei und Überweisungsdetails
`list_connections`	—	Bankverbindungen/Einwilligungen: Status, `valid_until`, `last_synced_at`, Anzahl der Konten

Alle Werkzeuge sind schreibgeschützt. Es gibt bewusst keine Synchronisierungs-, Zahlungsauslösungs- oder Einwilligungsverwaltungswerkzeuge – siehe Einschränkungen.

Related MCP server: saldo-mcp

Konfiguration

Env-Variable	Erforderlich	Bedeutung
`OBI_CREDENTIALS`	bevorzugt	Pfad zu (oder Inline-JSON von) dem aus der open-banking.io-App exportierten Anmeldedaten-Bundle – enthält `apiBaseUrl`, `apiKey` und den privaten Verschlüsselungsschlüssel
`OBI_API_KEY`	Alternative	API-Schlüssel, falls Sie das Bundle nicht verwenden
`OBI_PRIVATE_KEY`	Alternative	Base64-PKCS#8-EC (SECP256R1) privater Schlüssel, der zu `OBI_API_KEY` passt
`OBI_BASE_URL`	mit Alternative	API-Basis-URL (die `apiBaseUrl` des Bundles), erforderlich bei Verwendung der getrennten Umgebungsvariablen

Exportieren Sie die Anmeldedaten in der App → Einstellungen → Anmeldedaten, um die Bundle-Datei zu erhalten.

Claude Desktop

claude_desktop_config.json (Claude → Einstellungen → Entwickler → Konfiguration bearbeiten):

{
  "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"
      }
    }
  }
}

Erfordert uv (curl -LsSf https://astral.sh/uv/install.sh | sh). Sobald es auf PyPI veröffentlicht ist, kann das Argument --from git+… weggelassen werden.

Lokal ausführen / aus dem Quellcode

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

Beispielfragen für Ihren Agenten

„Zeige den gebuchten Saldo jedes Kontos.“
„Wie viel habe ich im Juli für Lebensmittel ausgegeben?“ (get_transactions + Gruppierung)
„Welche meiner Bankverbindungen laufen bald ab?“ (list_connections)

Design-Hinweise

Von Natur aus schreibgeschützt. Nur die get_*-Methoden des SDK werden bereitgestellt. sync/sync_all existieren im SDK, werden aber bewusst nicht angeboten; Agenten können über diesen Server kein Geld bewegen oder Einwilligungen ändern.
Exaktes Geld. Beträge werden als exakte Dezimalzeichenfolgen zurückgegeben ("1234.56"), niemals als Gleitkommazahlen.
Saubere Fehler. Fehlende Anmeldedaten, ungültige Daten, unbekannte Konten-IDs und Upstream-HTTP-Fehler werden als umsetzbare Werkzeugfehler angezeigt (z. B. Auflistung gültiger Konten-IDs bei einem Fehlschlag).
Kontextfreundlich. get_transactions verwendet standardmäßig 50 Einträge und begrenzt auf 500, um die Kontextfenster des Agenten zu schützen; verwenden Sie offset zum Paginieren.

Einschränkungen (ehrliche Liste)

Keine Schreibwerkzeuge: keine Synchronisierung, keine Zahlungsauslösung, keine Einwilligungserstellung/-verlängerung. Die Verlängerung von Einwilligungen erfolgt immer in der open-banking.io-App (PSD2 SCA).
Kein Bank-/Institutsverzeichnis-Werkzeug: Die Upstream-API (SDK v1.0.0) stellt keinen öffentlichen ASPSP-Such-Endpunkt bereit – TODO, falls/wenn die API einen hinzufügt.
Noch nicht auf PyPI – Installation über uvx --from git+… (oben) oder aus dem Quellcode. Die Veröffentlichung auf PyPI als open-banking-io-mcp ist geplant.
Datenminimierung liegt in Ihrer Verantwortung: Transaktionen enthalten Gegenparteien und Überweisungstext; richten Sie diesen Server nur an MCP-Clients, denen Sie vertrauen, und bevorzugen Sie lokale MCP-Clients (Claude Desktop / Cursor) gegenüber gehosteten aus Datenschutzgründen.

Eingebundene API-Oberfläche

SDK-Aufruf	HTTP (hinter dem 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`

Authentifizierung: X-Api-Key-Header. Antworten enthalten Zero-Knowledge-Umschläge (ECDH P-256 → HKDF-SHA256 → AES-256-GCM), die lokal vom SDK entschlüsselt werden. Vollständiges Drahtformat: clients-Repo · THREAT_MODEL.md.

Lizenz

MIT – wie die clients SDK-Repos.

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.

Name	Required	Description	Default
`account_id`	Yes

Output 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).

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

Output 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.

Name	Required	Description	Default
No parameters

Output 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.

Name	Required	Description	Default
No parameters

Output 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

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
https://api.thoughtbox.ai/mcp
BankBridgeOAuth
money.bankbridge
Read-only banking and personal finance for AI agents: accounts, transactions, spending, budgets.
Finance Databases
2
https://bankbridge.money/api/mcp
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
https://www.claritytrack.ai/mcp
wimm B
my.wimm
Personal finance for AI agents — onboard, import statements, categorize & budget over MCP.
Finance Data Platforms
432
https://wimm.my/api/mcp

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)
24 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 9 days ago (2026-10-22 12:56 UTC)
12
199 npm
296
MIT