Labsco
MCP SERVER

Run a Qonto organisation from the client — accounts, cards with their limits, SEPA and international transfers, invoicing, supplier bills, payment links and webhooks — with Strong Customer Authentication handled as a resumable session rather than a dead end.

Payments, Billing & SubscriptionsVerified
Summary
Strong Customer Authentication is part of the tool contract rather than a wall the agent runs into.

Operations that can move money say so in their own descriptions, poll inline, and then hand back a structured pending response carrying a session token, so the flow resumes through a status check and a retry instead of failing outright — which is what makes a scripted transfer to a trusted beneficiary complete without a human at the terminal. Irreversible actions are labelled as irreversible, and the ones needing a partner-only scope say which scope, so an agent finds out from the description rather than from a 403.

What it is

An independent, open-source toolkit for the Qonto banking API — a CLI, an MCP server and a library, running locally on your own credentials. It is not affiliated with Qonto, who publish their own hosted server; this one exists to automate the bank rather than to chat with it, including headless from a script or a CI job, and it supports several organisations from one setup through named profiles.

What you get
  • Accounts and money movement: account_list, account_create, account_update and account_close, transaction_list filtered by side, status and emission or settlement dates, statement_list, and internal_transfer_create between two accounts in the same organization.
  • SEPA transfers with payee verification attached: transfer_create against an existing beneficiary or an inline one, transfer_cancel, transfer_proof as a PDF, transfer_verify_payee and transfer_bulk_verify_payee, and bulk_transfer_create, which resolves the verification proof itself when it is not supplied.
  • Recurring transfers created with a frequency and a first execution date, then listed, shown and cancelled.
  • International payments: intl_eligibility, intl_currencies, intl_quote_create for a rate, intl_beneficiary_requirements and intl_transfer_requirements for the fields a given corridor demands, and intl_transfer_create against a quote.
  • Cards as a full lifecycle: card_create with its spending limits, options and restrictions set upfront, card_bulk_create for up to 50, lock and unlock, report lost, report stolen and discard — each marked irreversible — separate tools for limits, nickname, options and restrictions, card_appearances, and card_iframe_url for a secure view of the PAN, CVV and expiry.
  • Client billing end to end: client records, quote_create and quote_send, and a client invoice lifecycle of create, update, finalize — which assigns the number and moves it from draft to unpaid — send by email, mark and unmark paid, cancel, delete, and file uploads attached to the invoice.
  • Supplier invoices created by uploading files from the filesystem, listed with filters, plus credit notes.
  • Requests as an approval flow: request_list, request_approve and request_decline, with request_create_flash_card, request_create_virtual_card and request_create_multi_transfer, which carries a whole batch of transfers in one request.
  • The surrounding estate: attachments on transactions, payment links with their payments, methods and connection status, Qonto Terminal payments, labels, teams, memberships and invitations, insurance contracts, the product catalogue, e-invoicing settings, and webhook subscriptions.
  • diagnose, a read-only healthcheck against the configured profile returning per-check status of ok, warn, fail or skip with detail and suggested actions.
Requirements

Node.js 24 or newer, a Qonto business account with API access, and a configured profile — run diagnose first, it is the read-only check that the configuration works. Which half of this surface you get depends on the credential: an API key covers most reads and many writes but is production-only, while cards, teams, webhooks, e-invoicing, payment links, insurance, international transfers, recurring transfers and the sandbox need OAuth. Someone must be able to answer a Strong Customer Authentication challenge, since operations that move money or change cards may raise one — the tool polls inline for 30 seconds and otherwise hands back a session to resume from. The project is licensed AGPL-3.0, which constrains how anything built on it may be distributed.

Setup effort

One command plus a key — npx qontoctl mcp, then supply credentials