BankMCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APP_NAME | No | Optional display name shown on the sign-in and status pages. Defaults to 'BankMCP™'. | |
| BASE_URL | No | Public base URL of the server (e.g., https://your-host). Railway and Fly set this automatically. | |
| DATA_DIR | No | Directory for persistent state (default: /data). | |
| EB_APP_ID | No | The Enable Banking application ID (UUID) obtained from the Enable Banking dashboard. | |
| TLS_KEY_PATH | No | Optional path to TLS key file, used for local HTTPS. | |
| TLS_CERT_PATH | No | Optional path to TLS certificate file, used for local HTTPS. | |
| ADMIN_PASSWORD | No | Plain-text admin password (used for login). Alternative to ADMIN_PASSWORD_HASH. | |
| EB_PRIVATE_KEY | No | The contents of the private key .pem file, base64-encoded (e.g., using `base64 -i app.pem | tr -d '\n'`). Alternative to EB_PRIVATE_KEY_PATH. | |
| DEFAULT_COUNTRY | No | ISO country code (e.g., DK) used to filter banks during discovery. | |
| NOTIFY_WEBHOOK_URL | No | Optional webhook URL for watch notifications and sign-in alerts (e.g., a Slack incoming webhook). | |
| ADMIN_PASSWORD_HASH | No | Hashed admin password, generated via `npm run hash-password`. Alternative to ADMIN_PASSWORD. | |
| EB_PRIVATE_KEY_PATH | No | File system path to the private key .pem file. Alternative to EB_PRIVATE_KEY. | |
| ALLOWED_REDIRECT_HOSTS | No | Comma-separated list of allowed MCP client domains for OAuth redirects. Defaults to known clients (Claude, ChatGPT, etc.). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_banksA | Banks available through Enable Banking in a country, with the maximum consent length. Use the exact |
| start_consentA | Start linking a bank. Returns a URL the account holder must open in a browser to log in at their bank and approve read-only access. After approval the bank redirects back to this server and the accounts appear in list_accounts. Consents last up to 180 days. |
| consent_statusA | Which banks are connected, how many days each consent has left, and any bank logins that were started but not finished. |
| disconnect_bankA | Revoke a bank consent at Enable Banking and forget its accounts, labels and watches on this server. |
| list_accountsA | All linked accounts with bank, IBAN, currency and consent expiry. With include_balances the booked balance is fetched for each account (one bank call per account). Use the |
| set_account_labelA | Give an account a name you will recognise, e.g. 'Joint expenses' or 'Mortgage'. Labels can be used instead of uids in every other tool. |
| get_balancesA | Current balances of one account. |
| get_transactionsA | Transactions of one account, newest first. Amounts are signed (negative = money out). Defaults to the last 30 days. Banks return limited history (often 90 days, some up to 2 years). If the result has |
| create_watchA | Watch an account in the background and send a notification to the webhook the server's operator configured (NOTIFY_WEBHOOK_URL; Slack or any URL) when a rule fires. The destination cannot be chosen here. Accounts are checked at most 4 times a day, the limit PSD2 sets for unattended access. Rules: balance_below / balance_above: |
| list_watchesB | All watches with their rule, status and when they last fired. |
| delete_watchA | Remove a watch by id. |
| check_watchesA | Evaluate every active watch right now (counts as an attended check, so it does not wait for the polling slot) and return what fired. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| connect-bank | Walk the account holder through linking a bank (or renewing an expired consent). |
| savings-scan | For the vague 'how am I doing?' question. A 90-day scan that returns at most three findings ranked by money at stake and urgency: about to run short, a needless cost, or a regular payment that changed. Each with a concrete action. Not a monthly category review. |
| monthly-summary | Income, spending by category and the biggest items for one month, across all accounts. |
| subscription-audit | Find recurring charges, their yearly cost, price increases and anything new. |
| unusual-transactions | Large, duplicated or first-time transactions in a recent window compared to the months before. |
| build-budget | Turn the last months of real spending into a monthly budget per category, with a savings target and the levers that get there. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Tools are mostly distinct: account queries (get_balances, get_transactions), consent lifecycle (start_consent, consent_status, disconnect_bank), account listing/labeling, and watch management (create_watch, list_watches, delete_watch, check_watches). Minor overlap between list_accounts and get_balances (both return booked balances) and between check_watches and create_watch's notification behavior, but descriptions clarify the differences.
Most tools follow a clear verb_noun pattern: get_balances, get_transactions, list_banks, list_accounts, list_watches, start_consent, delete_watch, disconnect_bank. Minor deviations: create_watch vs. delete_watch/list_watches (could be add_watch for consistency), and consent_status/check_watches/set_account_label are noun-ish or verb_noun but not perfectly parallel. Overall predictable.
12 tools is well-scoped for a banking aggregation server. Each tool covers a distinct part of the workflow: bank discovery, consent management, account access, labeling, transaction history, and watch rules. No redundant or filler tools.
The surface covers the core banking aggregation lifecycle: connect banks, list accounts, read balances/transactions, label accounts, and manage watches. Minor gaps: no tool to update a watch or refresh a consent, and no explicit way to fetch a single transaction or account detail beyond balances, but agents can work around these with existing tools.