# Enable Banking (npm · @foreverworks/mcp-enable-banking)

Read, search and export statements and balances from banks across Europe, without moving money.

- Trust score: 82/100 (high trust)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- npm · `@foreverworks/mcp-enable-banking`: 82/100 (this document), [markdown](https://verifymcp.io/servers/com-foreverworks-enable-banking/foreverworks-mcp-enable-banking.md), [page](https://verifymcp.io/servers/com-foreverworks-enable-banking/foreverworks-mcp-enable-banking)

## Channel facts

- Registry: `npm`
- Package: `@foreverworks/mcp-enable-banking`
- Version: `0.1.1`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Supply Chain Security**: 98/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - No install/post-install scripts declared.
  - 7 of 23 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 100/100
  - Source repository is publicly reachable at the declared URL.
  - Cryptographically verified build provenance (signed, bound to foreverworks/mcps).
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 4 days ago).
  - Publishes a security disclosure policy (SECURITY.md).
- **Schema Quality & AI Usability**: 67/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 1898 tokens (~189/item across 10 items; 10 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 33/100
  - Stability observed for 10 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 98/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 93% of tool parameters carry a description.
- **Tool Safety**: 75/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - 0 of 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "revoke_session" implies "revoke" and declares no destructiveHint at all, which the MCP spec reads as destructive by default.
  - An AI judge read all 11 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a current MCP spec version (2026-07-28).

## Install

### How do I install the Enable Banking MCP server?

Enable Banking runs locally as an npm package, launched with npx -y @foreverworks/mcp-enable-banking. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add com-foreverworks-enable-banking -- npx -y @foreverworks/mcp-enable-banking
```

### Cursor

```json
{
  "mcpServers": {
    "com-foreverworks-enable-banking": {
      "command": "npx",
      "args": [
        "-y",
        "@foreverworks/mcp-enable-banking"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "com-foreverworks-enable-banking": {
      "command": "npx",
      "args": [
        "-y",
        "@foreverworks/mcp-enable-banking"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add com-foreverworks-enable-banking -- npx -y @foreverworks/mcp-enable-banking
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "com-foreverworks-enable-banking": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "@foreverworks/mcp-enable-banking"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add com-foreverworks-enable-banking --command npx --arg -y --arg @foreverworks/mcp-enable-banking
```

### Hermes

```yaml
mcp_servers:
  com-foreverworks-enable-banking:
    command: "npx"
    args: ["-y", "@foreverworks/mcp-enable-banking"]
```

### Netclaw

```json
{
  "McpServers": {
    "com-foreverworks-enable-banking": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "@foreverworks/mcp-enable-banking"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add com-foreverworks-enable-banking -t stdio -c npx -a -y @foreverworks/mcp-enable-banking
```

### Other

```json
{
  "mcpServers": {
    "com-foreverworks-enable-banking": {
      "command": "npx",
      "args": [
        "-y",
        "@foreverworks/mcp-enable-banking"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-03 (score 82, +1)

No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-11-01 (score 81, +16)

- [security improvement] Malware scan: unverified → pass

### 2026-10-31 (score 65, −15)

- [security regression] Malware scan: pass → unverified
- [functional] Package version: 0.1.0 → 0.1.1

### 2026-10-30 (score 80, +1)

No change was recorded against any check on this day. Stability & Change Management went from 10 to 13. That category is still filling its 30-day observation window: 3 days of observed history at the previous scan, 4 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-28 (score 79, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-26 (score 78)

First indexed and scored.

## MCP tools (10)

### `complete_auth` (~224 tokens)

Finish a bank consent

Exchange the code from the bank's redirect for a session and store it under label, replacing the consent stored there (the previous sessions.json is copied to sessions.json.bak first); without a label, a renewal replaces the stored consent for the same bank, country and psu_type. Takes the WHOLE redirect URL or just its code. The code is single-use and expires within minutes, so run this straight after the approval. The session is written to disk before anything else, because Enable Banking reveals the session id exactly once. Returns the authorised accounts (IBAN, currency, name, as the bank describes them now) and when the consent ends.

Input parameters:

- `code_or_url` (string, required): The full redirect URL (...?code=...&state=...), or the code value alone.
- `label` (string): What to store it under: a-z, 0-9, _ and -. Default: the label of the stored consent for the same bank, country and psu_type (a renewal replaces it), else the bank and country, like example_bank_de.

### `export_transactions` (~306 tokens)

Export transactions as CSV

The same statement as get_transactions (same arguments, same filters, same reads at the bank), written as a CSV file instead of returned: one row per transaction with its account, dates, direction, signed exact amount, currency, counterparty, payment reference and status. Returns the file's path, size and SHA-256, and how many rows it holds. Use it for a long period or many accounts, or when the result is meant for a spreadsheet or an accountant.

Input parameters:

- `account_uid` (string): One account: the uid field from list_accounts (a UUID, not the IBAN). Leave out to read every account on a consent.
- `amount_max` (string): Keep rows of at most this size, sign ignored.
- `amount_min` (string): Keep rows of at least this size, sign ignored, as a plain decimal such as "250" or "1200.50".
- `date_from` (string): YYYY-MM-DD, inclusive.
- `date_to` (string): YYYY-MM-DD, inclusive.
- `direction` (string): credit: money in; debit: money out.
- `label` (string): Every account on this stored consent (a label from list_stored_sessions). Leave out, with account_uid, to read every stored consent.
- `text` (string): Keep rows whose counterparty name or IBAN, payment reference or entry reference contains this; case and diacritics ignored.
- `transaction_status` (string)

### `get_balances` (~111 tokens)

Get balances

The balances the bank reports for one account uid: every type it sends (booked, available, interim, and so on), each with the PSD2 code as sent and its meaning spelled out, a reference date where the bank gives one, and the amount as an EXACT decimal string signed by the bank (negative when overdrawn). One read at the bank per call, like a statement.

Input parameters:

- `account_uid` (string, required): The uid field from list_accounts (a UUID, not the IBAN).

### `get_transactions` (~474 tokens)

Get transactions

A statement: the transactions of one account (account_uid), of every account on one consent (label), or of every account on every stored consent (neither), following the bank's pagination to the end. Each account read spends one of the few reads the bank allows per account per day (about four), so read once and narrow with the filters rather than reading again: text, direction, amount_min and amount_max run here, after the read, and cost nothing more.

Dates are YYYY-MM-DD and empty means unbounded. transaction_status takes a friendly name (booked, pending, cancelled, hold, other, rejected, scheduled) or a PSD2 code; empty omits the filter, which is NOT the same as asking for booked.

Each row carries a SIGNED decimal amount as a string, negative for money leaving the account, and a counterparty resolved against the direction rather than copied from one fixed field. Amounts are strings because they are exact: parse them yourself if you need arithmetic. An amountWarning appears only on a row whose figure could not be taken at face value. Reading several accounts, each row also names its account, and one account that fails is reported in accounts without hiding the others. For more rows than a reply should hold, export_transactions writes the same statement as CSV.

Input parameters:

- `account_uid` (string): One account: the uid field from list_accounts (a UUID, not the IBAN). Leave out to read every account on a consent.
- `amount_max` (string): Keep rows of at most this size, sign ignored.
- `amount_min` (string): Keep rows of at least this size, sign ignored, as a plain decimal such as "250" or "1200.50".
- `date_from` (string): YYYY-MM-DD, inclusive.
- `date_to` (string): YYYY-MM-DD, inclusive.
- `direction` (string): credit: money in; debit: money out.
- `label` (string): Every account on this stored consent (a label from list_stored_sessions). Leave out, with account_uid, to read every stored consent.
- `text` (string): Keep rows whose counterparty name or IBAN, payment reference or entry reference contains this; case and diacritics ignored.
- `transaction_status` (string)

### `health` (~62 tokens)

Health

Check that the integration is alive and say so in detail: the Enable Banking application the key pair authenticates as, its environment and redirect URL, where the config, key and sessions are, and how many consents are stored. Run this before concluding the MCP is broken.

### `list_accounts` (~73 tokens)

List accounts on a consent

The accounts a stored consent currently reaches, asked of the API rather than replayed from disk, because a bank can drop an account from a live consent. The uid field is what get_transactions takes.

Input parameters:

- `label` (string): A label from list_stored_sessions; may be left out when only one consent is stored.

### `list_aspsps` (~104 tokens)

List banks

List the banks Enable Banking can reach, by two-letter country code. The name field is what start_auth takes, psuTypes says whether the bank exposes personal accounts, business accounts or both, and maxConsentDays is how long that bank will let a consent last. Pass an empty country for every bank in every market. Served from a one-hour cache.

Input parameters:

- `country` (string, required): Two-letter code, like RO. Empty means every market, a large answer.

### `list_stored_sessions` (~71 tokens)

List stored consents

Every stored consent: its label, the bank, the accounts it covered, and when it EXPIRES (date and days left). A lapsed consent needs the account holder to approve a new one in the bank app, so check this first when a statement suddenly fails, and before one runs out.

### `revoke_session` (~130 tokens)

Revoke a bank consent

End a stored consent: Enable Banking is asked to close the session, which ends the bank's consent, and the label is removed from the stored consents (the file as it was is kept as a backup). Afterwards nothing can read those accounts until the account holder approves a new consent in their bank, so use it only when access should really stop (an account closed, an application retired, access no longer wanted). A consent the bank already ended is removed just the same. The label is required, always.

Input parameters:

- `label` (string, required): The consent to end, as list_stored_sessions names it.

### `start_auth` (~211 tokens)

Begin a bank consent

Begin a consent with one bank, valid for 180 days, over every account the bank offers. To renew a stored consent, pass the bank, country and psu_type list_stored_sessions shows for it. Returns a URL a HUMAN must open: the bank requires strong customer authentication, so this step cannot be automated. After approval the bank redirects to the configured redirect_url with ?code=... in the query; that URL, or just the code, goes into complete_auth. Moves money or makes a legal document: the client asks the user to approve each call.

Input parameters:

- `aspsp_country` (string, required): The bank's two-letter country code.
- `aspsp_name` (string, required): The bank: the name field from list_aspsps, exactly as spelled there.
- `psu_type` (string, required): Whose accounts: business or personal (list_aspsps says which the bank offers).
- `state` (string): Echoed back on the redirect; useful to tell flows apart.

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/com-foreverworks-enable-banking/foreverworks-mcp-enable-banking#diagnostics

## Score history

- 2026-11-05: 82
- 2026-11-04: 82
- 2026-11-03: 82
- 2026-11-02: 81
- 2026-11-01: 81
- 2026-10-31: 65
- 2026-10-30: 80
- 2026-10-29: 79
- 2026-10-28: 79
- 2026-10-27: 78
- 2026-10-26: 78

## Common questions

### What is the Enable Banking MCP server?

Enable Banking is an MCP server listed in the public MCP registry as com.foreverworks/enable-banking. Read, search and export statements and balances from banks across Europe, without moving money. This page covers its npm package (@foreverworks/mcp-enable-banking).

### Is the Enable Banking MCP server safe to use?

Enable Banking scores 82 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 5 November 2026. It declares no install or post-install scripts. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Enable Banking MCP server expose?

Enable Banking exposes 10 tools: complete_auth, export_transactions, get_balances, get_transactions, health, and 5 more. Their descriptions and schemas cost roughly 1,766 tokens of context every time the server is loaded.

### Is the Enable Banking MCP server still maintained?

Enable Banking is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the Enable Banking MCP server under?

Enable Banking declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- npm package: https://www.npmjs.com/package/@foreverworks/mcp-enable-banking
- Socket report: https://socket.dev/npm/package/@foreverworks/mcp-enable-banking
- Repository: https://github.com/foreverworks/mcps
- Website: https://foreverworks.github.io/mcps/servers/enable-banking/
- Changelog RSS feed: https://verifymcp.io/servers/com-foreverworks-enable-banking/foreverworks-mcp-enable-banking.xml
- Changelog JSON feed: https://verifymcp.io/servers/com-foreverworks-enable-banking/foreverworks-mcp-enable-banking.json
- HTML version of this page: https://verifymcp.io/servers/com-foreverworks-enable-banking/foreverworks-mcp-enable-banking