How do I use open-banking-io MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@open-banking-io MCP Server Show my account balances and recent transactions." 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.

de en es ja ko ru zh

open-banking-io MCP Server

by open-banking-io

Overview Schema Related Servers Score Discussions

Python

Remote

open-banking.io MCP server

A thin, read-only Model Context Protocol server for the open-banking.io PSD2 API. It lets AI agents (Claude Desktop, Cursor, any MCP client) answer questions like “What's my balance?” and “Summarise last month's transactions” over your own bank accounts.

It wraps the official open-banking-io Python SDK and inherits its zero-knowledge property: the service only ever returns ciphertext, and every sensitive field (IBAN, owner name, amounts, counterparties) is decrypted in-process with your exported private key. No plaintext ever touches a third party — including the LLM only sees what your MCP client sends it.

Tools

Tool	Arguments	Description
`list_accounts`	—	Bank accounts: bank, country, IBAN, owner, display name, currency, balances, `needs_reconnect` flag
`get_balances`	`account_id`	ISO 20022 balances for one account (`ITBD` = booked, `ITAV` = available)
`get_transactions`	`account_id`, `date_from?`, `date_to?`, `limit?` (default 50, max 500), `offset?`	Statement lines, newest first, with counterparty and remittance details
`list_connections`	—	Bank connections/consents: status, `valid_until`, `last_synced_at`, account count

All tools are read-only. There are intentionally no sync, payment-initiation or consent-management tools — see Limitations.

Related MCP server: plaid-mcp

Configuration

Env var	Required	Meaning
`OBI_CREDENTIALS`	preferred	Path to (or inline JSON of) the credentials bundle exported from the open-banking.io app — contains `apiBaseUrl`, `apiKey` and the encryption private key
`OBI_API_KEY`	alternative	API key, if you don't use the bundle
`OBI_PRIVATE_KEY`	alternative	Base64 PKCS#8 EC (SECP256R1) private key matching `OBI_API_KEY`
`OBI_BASE_URL`	with alternative	API base URL (the bundle's `apiBaseUrl`), required when using the split env vars

Export credentials in the app → Settings → Credentials to get the bundle file.

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

Requires uv (curl -LsSf https://astral.sh/uv/install.sh | sh). Once published to PyPI the --from git+… argument can be dropped.

Run locally / from source

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

Example questions for your agent

“Show the booked balance of every account.”
“How much did I spend on groceries in July?” (get_transactions + grouping)
“Which of my bank connections expire soon?” (list_connections)

Design notes

Read-only by construction. Only the SDK's get_* methods are exposed. sync/sync_all exist in the SDK but are deliberately not offered; agents cannot move money or alter consents through this server.
Exact money. Amounts are returned as exact decimal strings ("1234.56"), never floats.
Clean errors. Missing credentials, bad dates, unknown account ids and upstream HTTP errors are surfaced as actionable tool errors (e.g. listing valid account ids on a miss).
Context-friendly. get_transactions defaults to 50 items and clamps at 500 to protect agent context windows; use offset to paginate.

Limitations (honest list)

No write tools: no sync, no payment initiation, no consent creation/renewal. Consent renewal always happens in the open-banking.io app (PSD2 SCA).
No bank/institution directory tool: the upstream API (SDK v1.0.0) does not expose a public ASPSP-search endpoint — TODO if/when the API adds one.
Not yet on PyPI — install via uvx --from git+… (above) or from source. Publishing to PyPI as open-banking-io-mcp is planned.
Data minimisation is your responsibility: transactions include counterparties and remittance text; only point this server at MCP clients you trust, and prefer local MCP clients (Claude Desktop / Cursor) over hosted ones for privacy.

API surface wrapped

SDK call	HTTP (behind the 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`

Auth: X-Api-Key header. Responses carry zero-knowledge envelopes (ECDH P-256 → HKDF-SHA256 → AES-256-GCM) decrypted locally by the SDK. Full wire format: clients repo · THREAT_MODEL.md.

License

MIT — same as the 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.

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. Dates show when Glama detected each change.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0

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

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

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 bank access for your AI agent. Connects Claude, ChatGPT, Cursor, Gemini, Codex.
Finance Databases
2
wimmOAuth
my.wimm
Personal finance for AI agents — onboard, import statements, categorize & budget over MCP.
Finance Data Platforms
2
Wise PennyOAuth
app.wisepenny
Chat with your bank data: balances, transactions, budgets, bills. Reads only, never moves money.
Finance Search
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)
-
plaid-mcp
Finance Databases Customer Data Platforms
t-rhex
A
license
A
quality
D
maintenance
A read-only MCP server that enables users to analyze their real bank, credit card, loan, and brokerage data through Plaid. It provides financial analysis tools for transactions, balances, investments, liabilities, and debt while keeping all access tokens and data locally stored.
Updated 5 months ago (2026-04-22 01:31 UTC)
24
MIT
saldo-mcp
Finance Security
pixby
A
license
Not graded
quality
B
maintenance
A read-only MCP server that securely connects Swedish/Nordic bank accounts to AI assistants, keeping all financial data local and encrypted.
Updated 2 months ago (2026-07-21 22:49 UTC)
21
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 a month ago (2026-08-10 20:36 UTC)
5
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/open-banking-io/mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server