Skip to main content
Glama
614,719 tools. Updated 2026-09-26 23:22

"Starling Bank" matching MCP tools:

  • Returns accounts for a bank connection: BANK (checking/savings) and CREDIT (credit card) with balance, number, type, subtype, bankData, and creditData. Also returns `bank` (the brand/connector name like 'Nubank Empresas' — same shown in the dashboard UI) and `connector_id`. Note: each account's `name` is the legal entity that issues the account (e.g. 'Nu Pagamentos S.A. - Instituição de Pagamento'), which is not the same as the brand — when referring to the bank in user-facing text, use `bank`. OMIT `item` to list accounts across ALL linked banks at once — the response aggregates every connection's accounts into `results`, each row tagged with its own `bank`/`connector_id`/`item_id` (use this when the user asks for 'my accounts/cards' without naming a bank). Pass `item` to target a single bank (response carries `bank`/`connector_id`/`item_id` at the root). CREDIT (credit card) `balance`: its meaning is CONNECTOR-DEPENDENT — some banks report the current open-bill partial, others the full revolving/installment debt — so do NOT treat `balance` as 'this month's bill'. The open billing cycle is defined by `creditData.balanceCloseDate` (when it closes) / `balanceDueDate` (when it's due). For a standardized open-bill amount and total debt that mean the same across connectors, use openfinance_list_credit_card_bills (`open_bill` + `total_pending_debt`, derived from PENDING transactions); closed bills come from that same tool's `results`. A CREDIT row may carry `creditData.usedAmount` (how much of THIS card's limit the bank reports as consumed) and a `balance_notice`. `balance_notice` means `balance` came back 0,00 while the bank's own payload indicates an outstanding amount — some issuers never fill the card's consolidated balance field. When it is present, do NOT tell the user the card has nothing to pay: read the amount from openfinance_list_credit_card_bills instead. `bankData.closingBalance` and `automaticallyInvestedBalance` are provider-reported extras that can LAG right after a connection is first created: the bank may publish the connection as UPDATED before those derived fields converge, so they can briefly carry a stale/phantom value that a force sync (openfinance_force_sync) reconciles. The account's own `balance` is authoritative — treat those two as hints until they agree with it. May include a `provider_incident` block when the Open Finance provider has an OPEN incident affecting a bank in this response: balances and credit limits may be unreliable (incomplete or wrong, e.g. a credit limit near 1,00) even with the connection UPDATED, until the provider recovers. Do not present those values as real. May include an `identity_notice` when the SAME account (same number) arrives via two connections stamped with DIFFERENT owner/taxNumber: in Open Finance those fields reflect each connection's CONSENT HOLDER (e.g. a joint account consented by both holders), so dedupe by account number before summing balances and do not attribute ownership by owner/taxNumber for those accounts. Bulk support: accepts item_ids for batched execution.
    ConnectorNo auth
  • Returns accounts for a bank connection: BANK (checking/savings) and CREDIT (credit card) with balance, number, type, subtype, bankData, and creditData. Also returns `bank` (the brand/connector name like 'Nubank Empresas' — same shown in the dashboard UI) and `connector_id`. Note: each account's `name` is the legal entity that issues the account (e.g. 'Nu Pagamentos S.A. - Instituição de Pagamento'), which is not the same as the brand — when referring to the bank in user-facing text, use `bank`. OMIT `item` to list accounts across ALL linked banks at once — the response aggregates every connection's accounts into `results`, each row tagged with its own `bank`/`connector_id`/`item_id` (use this when the user asks for 'my accounts/cards' without naming a bank). Pass `item` to target a single bank (response carries `bank`/`connector_id`/`item_id` at the root). CREDIT (credit card) `balance`: its meaning is CONNECTOR-DEPENDENT — some banks report the current open-bill partial, others the full revolving/installment debt — so do NOT treat `balance` as 'this month's bill'. The open billing cycle is defined by `creditData.balanceCloseDate` (when it closes) / `balanceDueDate` (when it's due). For a standardized open-bill amount and total debt that mean the same across connectors, use openfinance_list_credit_card_bills (`open_bill` + `total_pending_debt`, derived from PENDING transactions); closed bills come from that same tool's `results`. A CREDIT row may carry `creditData.usedAmount` (how much of THIS card's limit the bank reports as consumed) and a `balance_notice`. `balance_notice` means `balance` came back 0,00 while the bank's own payload indicates an outstanding amount — some issuers never fill the card's consolidated balance field. When it is present, do NOT tell the user the card has nothing to pay: read the amount from openfinance_list_credit_card_bills instead. `bankData.closingBalance` and `automaticallyInvestedBalance` are provider-reported extras that can LAG right after a connection is first created: the bank may publish the connection as UPDATED before those derived fields converge, so they can briefly carry a stale/phantom value that a force sync (openfinance_force_sync) reconciles. The account's own `balance` is authoritative — treat those two as hints until they agree with it. May include a `provider_incident` block when the Open Finance provider has an OPEN incident affecting a bank in this response: balances and credit limits may be unreliable (incomplete or wrong, e.g. a credit limit near 1,00) even with the connection UPDATED, until the provider recovers. Do not present those values as real. May include an `identity_notice` when the SAME account (same number) arrives via two connections stamped with DIFFERENT owner/taxNumber: in Open Finance those fields reflect each connection's CONSENT HOLDER (e.g. a joint account consented by both holders), so dedupe by account number before summing balances and do not attribute ownership by owner/taxNumber for those accounts. Bulk support: accepts item_ids for batched execution.
    ConnectorNo auth
  • Returns accounts for a bank connection: BANK (checking/savings) and CREDIT (credit card) with balance, number, type, subtype, bankData, and creditData. Also returns `bank` (the brand/connector name like 'Nubank Empresas' — same shown in the dashboard UI) and `connector_id`. Note: each account's `name` is the legal entity that issues the account (e.g. 'Nu Pagamentos S.A. - Instituição de Pagamento'), which is not the same as the brand — when referring to the bank in user-facing text, use `bank`. OMIT `item` to list accounts across ALL linked banks at once — the response aggregates every connection's accounts into `results`, each row tagged with its own `bank`/`connector_id`/`item_id` (use this when the user asks for 'my accounts/cards' without naming a bank). Pass `item` to target a single bank (response carries `bank`/`connector_id`/`item_id` at the root). CREDIT (credit card) `balance`: its meaning is CONNECTOR-DEPENDENT — some banks report the current open-bill partial, others the full revolving/installment debt — so do NOT treat `balance` as 'this month's bill'. The open billing cycle is defined by `creditData.balanceCloseDate` (when it closes) / `balanceDueDate` (when it's due). For a standardized open-bill amount and total debt that mean the same across connectors, use openfinance_list_credit_card_bills (`open_bill` + `total_pending_debt`, derived from PENDING transactions); closed bills come from that same tool's `results`. A CREDIT row may carry `creditData.usedAmount` (how much of THIS card's limit the bank reports as consumed) and a `balance_notice`. `balance_notice` means `balance` came back 0,00 while the bank's own payload indicates an outstanding amount — some issuers never fill the card's consolidated balance field. When it is present, do NOT tell the user the card has nothing to pay: read the amount from openfinance_list_credit_card_bills instead. `bankData.closingBalance` and `automaticallyInvestedBalance` are provider-reported extras that can LAG right after a connection is first created: the bank may publish the connection as UPDATED before those derived fields converge, so they can briefly carry a stale/phantom value that a force sync (openfinance_force_sync) reconciles. The account's own `balance` is authoritative — treat those two as hints until they agree with it. May include a `provider_incident` block when the Open Finance provider has an OPEN incident affecting a bank in this response: balances and credit limits may be unreliable (incomplete or wrong, e.g. a credit limit near 1,00) even with the connection UPDATED, until the provider recovers. Do not present those values as real. May include an `identity_notice` when the SAME account (same number) arrives via two connections stamped with DIFFERENT owner/taxNumber: in Open Finance those fields reflect each connection's CONSENT HOLDER (e.g. a joint account consented by both holders), so dedupe by account number before summing balances and do not attribute ownership by owner/taxNumber for those accounts. Bulk support: accepts item_ids for batched execution.
    ConnectorNo auth
  • Search banks and financial institutions by name, SWIFT/BIC code, or country. Covers both SWIFT-connected banks and non-SWIFT financial institutions (e-money issuers, payment processors, MFOs, brokerages, VASPs, etc.). Returns: SWIFT/BIC code (if any), name, city, country, institution type, GPI membership, a coarse sanctions FLAG across 7 hard-sanctions watchlists (OFAC SDN, EU, UK, CA, CH, AU, NZ — see sanctions_note; this is NOT a full screen, use sanctions_screen for a compliance verdict), and enriched bank profile when available. EVERY BANK COMES BACK SAYING WHETHER WE HOLD ITS CORRESPONDENT CHAIN. Read `settlement_instructions` on each bank: `on_file: true` with a `currencies_on_file` count means we hold that BIC8's actual correspondent BIC, nostro account number and national clearing ID, and `read_with` is the exact ssi_lookup call that returns them. `on_file: false` means we hold none in any currency — a gap in our data, not a finding about the bank. A null is "not established yet" and is neither. This is the answer to "which intermediary bank do I put on the instruction?", and it is a fact we either have or do not have — never one to recall from training data. The country parameter accepts both 2-letter ISO codes ("ID", "DE") and full English names ("Indonesia", "Germany"). Names are resolved automatically. A BIC IDENTIFIES AN OFFICE, NOT A BRAND, AND THE DIFFERENCE IS PRICED. A name search returns ONE representative office per bank, elected by BIC convention rather than by relevance to the payment, and `office_note` says so whenever the bank holds more than one. Published tariffs, correspondent chains and settlement instructions are filed per BIC, so the choice changes the answer: transfer_cost("COBADEFF") returns Commerzbank's published 0.15% sending fee and transfer_cost("COBADEBB") refuses for want of a filed tariff, and both of those are Commerzbank AG in Germany. So: - If the user named a CITY, put it in the query — "Commerzbank Frankfurt" resolves to the Frankfurt office, and the plain name cannot. - If they did not, ask which BIC is on their statement or payment instruction before pricing or routing, and say which office you used. - Never present a representative office's BIC as "the bank's BIC". Examples: swift_lookup("DEUTDEFF") # exact BIC lookup swift_lookup("Deutsche Bank") # search by name swift_lookup("Commerzbank Frankfurt") # bank + city -> that office's BIC swift_lookup("TBC PAY") # find non-SWIFT payment processor swift_lookup("bank", country="KZ") # explore banks in a country swift_lookup("Halyk", country="KZ") # find specific bank in country swift_lookup("Bank Mandiri", country="Indonesia") # full country name OK
    ConnectorNo auth
  • List all Plaid bank connections (items) for the user. Each item represents one institution (one bank login). A single item can hold multiple Account rows (checking + savings + credit card from the same bank). Args: include_inactive: Include unlinked / soft-deleted items (default: False) Returns: ``{"items": [...], "total_count": N}`` where each item carries id, institution_name, products (consented), last_synced_at, is_active, error_code/message, consent_expiration_time, and the count of currently-linked accounts.
    ConnectorAPI key
  • Fetch one or more Bank of England IADB series by code over a date range. Requires BoE series codes (e.g. IUDBEDR = Bank Rate, IUDSOIA = SONIA, XUDLUSS = USD/GBP, XUDLERS = EUR/GBP). Use list_known_series or the convenience tools (bank_rate, sonia, usd_gbp, eur_gbp) if you do not know the code. Returns parsed JSON: one entry per series with observations [{date, value}].
    ConnectorNo auth

Matching MCP Servers

  • A
    license
    Not graded
    quality
    A
    maintenance
    MCP server for Starling Bank API integration, enabling AI agents to manage accounts, view transactions, and send payments via natural language.
    170 npm
    4
    MIT
  • A
    license
    A
    quality
    B
    maintenance
    Enables MCP clients to fetch official published exchange rates from 60+ central banks and tax authorities, with point-in-time lookup, history, and cross-bank comparison.
    5
    55 npm
    1
    MIT

Matching MCP Connectors

  • Norges Bank (Norway's central bank) MCP — exchange rates, interest rates,

  • Bank of Canada Valet API MCP. Keyless. Dates are YYYY-MM-DD.

  • Send dollars to a bank account Pay USDC to send dollars to a bank account by ACH. The x402 USDC price is the requested amount plus a 0.25% transfer fee (with a $1.50 minimum fee). On-chain payment credits the calling wallet's Laso account balance via the standard deposit webhook; the callable then debits the gross amount and queues the transfer. **A bank destination is required first.** `destination_id` comes from the banking callables: create the banking profile with `createBankingProfile`, register who is being paid with `createBankingRecipient`, and attach their bank account with `addBankingDestination`, which returns the id. List what you already have at `GET /bank-recipients` (free). See the [bank accounts guide](/guides/agent-bank-accounts) for the full setup. **Identity verification is required** on the account that owns the banking profile, and only the human owner can complete it. `createBankingProfile` hands back a `kycUrl` when it is outstanding. **If the payout cannot be fulfilled** (no approved banking profile, a destination that is not yours, an amount out of range), nothing is stranded: the USDC you paid has already credited your account balance. Fix the problem and retry, or recover it with `POST /withdraw`. **Settlement:** ACH, normally 1-2 business days. Follow it with `listBankingTransactions` / `getBankingTransaction`. **Fee:** 0.25% with a $1.50 minimum (included in the USDC price). PAID ROUTE (11.50-10025 USD): the x402 USDC price is paid automatically from your managed agent wallet. Make sure the wallet exists and is funded first (get_agent_wallet).
    Connector
    Destructive
    OAuth
  • Retrieves bank account details and recent transaction history via a connected bank API integration. Returns a list of transactions for the specified account, or for all linked accounts when no account ID is provided. Use bank_accounts when an agent needs to inspect account balances, review recent spending, categorise transactions, or reconcile records against a specific bank account. Prefer open_banking_transactions when the integration uses a PSD2 Open Banking provider (TrueLayer) covering 300+ UK and European banks — open_banking_transactions returns richer transaction metadata including merchant names, categories, and running balances. Prefer stripe_payments when the source of payments is a Stripe merchant account rather than a retail bank account. This tool requires a valid bank API credential to be configured on the server.
    ConnectorNo auth
  • Retrieves bank account details and recent transaction history via a connected bank API integration. Returns a list of transactions for the specified account, or for all linked accounts when no account ID is provided. Use bank_accounts when an agent needs to inspect account balances, review recent spending, categorise transactions, or reconcile records against a specific bank account. Prefer open_banking_transactions when the integration uses a PSD2 Open Banking provider (TrueLayer) covering 300+ UK and European banks — open_banking_transactions returns richer transaction metadata including merchant names, categories, and running balances. Prefer stripe_payments when the source of payments is a Stripe merchant account rather than a retail bank account. This tool requires a valid bank API credential to be configured on the server.
    ConnectorNo auth
  • Deletes a question bank or ONE of its items - "target" says which, and nothing else deletes either. target "bank" removes the bank and every item it holds (its tags cleaned up exactly as question_bank_tag(action: "remove") does), and is rejected with QUESTION_BANK_INTERDEPENDENCY while a Riddle of the bank's own project still references it - counting the DRAFT and, on a published Riddle, the live version too, so a block removed from a draft does not release the bank until that Riddle is republished; read "deletingABank" in riddle://reference/question-bank/overview before deleting one. target "item" takes questionBankItemId and touches nothing else: on a never-published item the delete is immediate and permanent, on a published one it only leaves the DRAFT - a live Riddle keeps drawing that item until question_bank_manage(action: "publish") purges it, and question_bank_discard_changes brings it back until then. Both are permanent for the caller: there is no trash and no restore. Rejected for a public template id - a template is copied with question_bank_manage(action: "duplicate"), never deleted.
    Connector
    Destructive
    No auth
  • Deletes a question bank or ONE of its items - "target" says which, and nothing else deletes either. target "bank" removes the bank and every item it holds (its tags cleaned up exactly as question_bank_tag(action: "remove") does), and is rejected with QUESTION_BANK_INTERDEPENDENCY while a Riddle of the bank's own project still references it - counting the DRAFT and, on a published Riddle, the live version too, so a block removed from a draft does not release the bank until that Riddle is republished; read "deletingABank" in riddle://reference/question-bank/overview before deleting one. target "item" takes questionBankItemId and touches nothing else: on a never-published item the delete is immediate and permanent, on a published one it only leaves the DRAFT - a live Riddle keeps drawing that item until question_bank_manage(action: "publish") purges it, and question_bank_discard_changes brings it back until then. Both are permanent for the caller: there is no trash and no restore. Rejected for a public template id - a template is copied with question_bank_manage(action: "duplicate"), never deleted.
    Connector
    Destructive
    No auth
  • List the business's expenses with amount, date, category account, linked bank transaction and notes. These are recorded expense entries; for recorded income use list_income, and for raw bank-feed lines use list_transactions.
    ConnectorOAuth
  • Report the business's bank-connection profile without pulling any transactions. Returns :providers (live Yodlee provider-link + per-dataset refresh health) AND :bankfeeds (per-provider connection status for every other linked bank feed — Capitec, GoCardless, Investec, Stripe and the other bank-connection apps — derived from stored install state, no live external call). A business with no Yodlee link still gets its :bankfeeds; only a business with no bank connection at all returns an explanatory :message, NOT an error.
    ConnectorOAuth
  • Reconcile one account against a bank statement for a period. Give the statement as CSV text or as rows (date, amount, description) you read off a PDF. Reports matched lines, lines the app is missing, ledger rows the bank never saw, and the closing-balance difference. Dry-run unless commit=true; then the missing rows are added as bank-confirmed, the unexplained ledger rows go to the review queue, and the run is recorded.
    Connector
    Destructive
    OAuth
  • Indian bank branch lookup by IFSC code. Resolves an 11-character IFSC code (printed on Indian cheques and bank statements) to the bank name, branch, address, city, district, state, MICR code, SWIFT code, and contact number, plus whether the branch supports the NEFT, RTGS, UPI, and IMPS payment rails. India banking / fund-transfer routing data via the open Razorpay IFSC dataset (keyless). Also returns an offline format_valid check of the code structure. NOTE: this validates and resolves the IFSC code itself — it does NOT verify a bank account or account holder. Examples: ifsc_lookup({ ifsc: "HDFC0CAGSBK" }), ifsc_lookup({ ifsc: "sbin0000691" }) (case and spaces are forgiven).
    ConnectorNo auth
  • Search 16,000+ World Bank development indicators by keyword or topic — GDP, population, poverty, education, health, environment, trade. Returns indicator ID, name, source, description, topics. Use indicator IDs with finance.country_data for time-series data (World Bank, CC BY 4.0)
    ConnectorNo auth
  • Aggregated World Bank poverty estimates at the regional/group level (not per-country). Returns headcount, poverty gap, mean welfare, and total population in poverty for each group. group_by controls the aggregation: "wb" = World Bank geographic regions, "inc" = income groups (HIC/UMIC/LMIC/LIC), "none" = global total.
    ConnectorNo auth
  • Work out which Nigerian banks a 10-digit NUBAN account number could belong to. The CBN check digit is computed from the bank code plus the first nine digits, so testing the number against every bank code narrows a shortlist without contacting any bank. Typically reduces ~30 banks to ~3. This confirms checksum validity only: it does NOT confirm the account exists, and it never returns the account holder's name, which requires a licensed NIBSS account-name enquiry.
    ConnectorNo auth
  • Is this bank code even well-formed? — Validate a BIC/SWIFT code offline (ISO 9362): 8 or 11 characters, bank/country/location[/branch] layout, head-office vs branch, and the test-BIC flag. Every rejection names which check failed. Structure only — does not prove the bank is live. Required input: bic. Priced $0.002 per call over x402 on Base; send a prepaid x-credit-token header for unlimited calls, or get 1 free call/day per tool. No wallet or API key required.
    ConnectorNo auth
  • BANK-ACCOUNT ACCESS for FOREIGN NON-RESIDENTS in a jurisdiction — two profiles: (a) non-resident individual, (b) foreign entity. Each carries the STATUTORY position AND the PRACTICAL bank appetite separately (many countries are legally open but practically closed — the two are never merged), plus typical KYC/document set, remote-opening availability, indicative minimums (bank policy, never law), timelines, CRS/FATCA notes and EDD triggers. Deepens the formation-linked banking landscape to 194-country coverage. Pass cc for one jurisdiction; omit for the covered list. Account opening is decided unilaterally by each bank — NO account opening is ever guaranteed; full CRS/FATCA transparency always. Information, not financial or legal advice.
    ConnectorNo auth
  • See whether the company's Xero books are posting: last spend/receive money-document date, authorized unmatched document count (deleted history excluded; full first page gives a lower bound), and a Bank Summary. Use when asked "are the books current?". feed_stale is statement/feed freshness — Xero Accounting API cannot see Reconcile-tab statement lines, so a quiet money-doc date is NOT a dead bank feed. Cash on /finance (Plaid) is not this number. Routing: Are the Xero books posting / money-doc age vs feed — get_xero_books_health, not get_cash_position. Quiet money-docs ≠ dead bank feed.
    ConnectorNo auth