Available banking operations via Model Context Protocol (MCP)
Protocol: JSON-RPC 2.0 over Streamable HTTP
MCP Endpoint: /mcp
Methods: tools/list, tools/call
Authentication: JWT in
Authorization header (from httpOnly
cookie via Agent), integration in
X-Bancony-Integration
Note: User tokens are stored in httpOnly cookies for security. The Agent reads the cookie and forwards the token to MCP Server via headers.
Get the user's bank accounts and cards. Returns each account with balances, identifiers (account number, plus IBAN/BBAN/BIC or masked PAN where the bank has them), holder, product, type, lifecycle status, and usage. Field shapes follow the Berlin Group PSD2 `accountDetails` model where they overlap.
Get bank transactions. Returns a list of transactions with amounts, dates, descriptions, and categories. The `verbosity` parameter selects between a compact default (`minimal`) and full transactions view (`full`) that surfaces every optional ISO 20022 / Open Finance field the server can populate. This tool returns data only — call it freely while reasoning and answer amount questions from it in ONE plain sentence. To DISPLAY results visually, use whichever display tools are in your toolset: `show-transactions` for a transaction list, `compare-spending` for a period comparison, `present-insight` for other charts, or `spending-summary` for the breakdown card — and only when the customer asked to SEE something. No display tool for it in your toolset → answer in text. For a company (netbanki fyrirtækja) this is also the cross-account statement — hreyfingar / færsluyfirlit spanning ALL the company's accounts by default; narrow with account_ids. get-accounts lists the accounts themselves (balances, IBANs), not their movements; balance-over-time questions are get-balance-history, not this.
NewestFirst OldestFirstLook up a single transaction by id and return every field the server can populate, including `counterparty` (with `postalAddress` for card entries) and the open `properties` bag of ISO 20022 / SEPA / card audit metadata (remittance text, end-to-end / mandate / creditor ids, purpose / transaction codes, MCC, masked PAN, etc.). Use this for audit / reconciliation flows; for compact lists prefer `get-transactions` with a `verbosity` cap.
Get transaction categories. Returns a list of categories that transactions can be classified into.
Get an aggregated summary of transactions, scoped to either income or expenses. Returns totals, counts, and averages, optionally grouped by category, month, or both. Filters mirror get-transactions: account, date, amount range, category ids. This tool returns data only — call it freely while reasoning and answer amount questions from it in ONE plain sentence. To DISPLAY results visually, use whichever display tools are in your toolset: `show-transactions` for a transaction list, `compare-spending` for a period comparison, `present-insight` for other charts, or `spending-summary` for the breakdown card — and only when the customer asked to SEE something. No display tool for it in your toolset → answer in text.
Income Expensesnone category month bothGet saved payment recipients filtered by name. Returns matching recipients with their account details. Pass an empty name ("") to list ALL saved recipients — use that when the customer asks what recipients they have; the customer's own accounts are excluded from that listing. Never claim a recipient does or does not exist without calling this tool first.
Execute a transfer the user has confirmed. Takes only the `transfer_intent_id` returned by `prepare-transfer`. The intent's amount, creditor, debtor, and rail are immutable: any change requires a new prepare call. Servers reject expired intents with a structured error.
SHOW the customer a large visual spending-breakdown card (donut chart or income-vs-spending bars) grouped by category, category group, month, or merchant. This is a DISPLAY tool: calling it always renders the big card in the chat, so call it ONLY when the customer explicitly asks to see, show, visualise, chart or break down their spending ("sýndu mér útgjöldin", "kökurit yfir útgjöldin", "spending overview"). For a QUESTION about an amount — how much they spent on something, in a category, at a merchant, or in a period ("hvað eyddi ég í skyndibita í síðasta mánuði?") — do NOT call this: use get-transactions-summary with category_ids or search_text and answer in one plain sentence. A scalar question deserves a scalar answer, not a full-screen chart.
Get the bank's brand kit — colours, chart palette, font and logo — to STYLE any chart, graph, dashboard, table or visual you create. Call this before building a visualization so it matches the bank's brand: use chartColors (in order) for series, primary/accent for highlights and headers, fontFamily for text, and put logoSvg in the header. Read-only; takes no input.
Present the answer to an open-ended, analytical question about the customer's money as a branded, interactive card. Use this AFTER you have gathered the data with the read tools (get-transactions, spending-summary, etc.): pick the archetype that best fits the answer and pass the data you computed. The bank's brand and the display language are applied automatically — do not pass them. Choose the archetype: • breakdown — parts of a whole ('where does my money go?'). • trend — a value over time ('is my spending going up?'). • comparison — two or more sides ('this year vs last', 'budget vs actual'). • ranked — a leaderboard ('top merchants', 'biggest payments'). • insight — a narrative finding + an optional supporting mini-viz. Write `content` as a plain-English summary; put any on-screen labels and titles in the user's language. The data tools (get-transactions, get-transactions-summary, get-unpaid-bills, get-loans) render their own branded cards for routine answers; reserve this for the ad-hoc, open-ended analysis they don't cover.
Compare the customer's spending in a window against the SAME window one year earlier, rendered as ONE interactive branded card (tap a month to drill into days and the underlying transactions; the card's own controls switch period, so one call also covers follow-ups). `window` is a single free-form string — ALWAYS carry the user's stated period into it verbatim: "May" → window='may'; "maí 2025" → window='maí 2025'; "Q2" → window='q2'; "2024" → window='2024'; nothing stated → omit (year-to-date). Optionally focus on one merchant via `merchant` — "how much did I spend at Bónus in May vs last year" → window='may', merchant='Bónus'. Expenses only; brand and language are applied automatically.
SHOW the customer their transactions as the bank's branded statement card (expandable table with PDF / Excel / CSV export). Call this when the user asks to SEE / show / display transactions ("sýndu mér færslurnar", "show me those transactions") — one call renders one card; never paste a transaction list as text instead. Filter with `description` (payee text), `category` (a spending category name, e.g. 'cycling' / 'matvara'), and either `window` (a period string: 'may', 'q2', '2025', '3m', omit for year-to-date) or explicit `start_date`/`end_date`. For reading data silently while analysing, use get-transactions instead.
Get the customer's loans and mortgage with full detail: outstanding balance, interest rate, whether a mortgage is indexed (verðtryggt) or not, the monthly payment, and how much of the latest payment went to principal versus interest. Use this when the user asks about their mortgage (húsnæðislán), car loan, student loan, personal loan, total debt, what rate they pay, or how much of a payment is interest. The result renders as visual loan cards in the customer's UI, so also call this when the user asks to see or show their loans or mortgage.
List the unpaid bills the holder has to PAY — Ógreiddir reikningar sem greiða þarf (e.g. utilities / Veitur, telecom / Síminn, property tax / fasteignagjöld, supplier invoices) — with status, due dates (gjalddagi / eindagi), amounts and a summary. Works for both individuals and companies (a company's accounts payable). Use when the user asks what they owe, about pending or overdue bills, or to see/show their unpaid bills. These are bills the holder OWES; for a company's receivables — kröfur it has issued, money owed TO it — use list-claims instead, and a company's public charges (VSK, staðgreiðsla, tryggingagjald) are listed by list-tax-obligations, not here. Each bill is a krafa settled individually against its kröfunúmer on the claims rail — incoming bills are never bundled into a greiðslubunki (create-payment-batch is for OUTGOING mass payments to payees, the opposite direction). Bills marked auto_pay=true are informational only — do not offer to pay them; they settle automatically on gjalddagi via beingreiðsla. If a bill is overdue, mention the dráttarvextir (late_fee) so the user knows the cost of waiting. The result renders as a visual bills card in the customer's UI.
List the holder's electronic-documents inbox — Rafræn skjöl: launaseðlar (payslips), greiðsluseðlar (payment slips for kröfur), reikningsyfirlit (monthly account statements) — newest first. Each document is exactly what a bank's inbox holds: a title, the date it arrived, and a per-document pdf_url. This is an INBOX LISTING, nothing more: use it only when the user asks about the documents themselves — 'sýndu mér launaseðilinn minn', what documents have arrived, when did the statement arrive, open my payment slip. It is the WRONG tool for amount or 'how much' questions: 'hvað fékk ég í laun' / what was I paid is answered from the salary credit in get-transactions; bill amounts come from get-unpaid-bills. The result carries NO document content — titles, senders, dates and links only — so never present figures as coming from a document you have not read. To let the user open a document, give them its pdf_url: a SHORT-LIVED signed link (expires within minutes) — offer it to open right away, never store it, quote it as a stable reference, or fetch it yourself; re-call this tool to mint fresh links. Reading a document's contents requires the separate fetch-document tool (if present) and the user's explicit request. A greiðsluseðill references its krafa via bill_id, so pair with get-unpaid-bills to connect a payment slip to the bill it settles; paying still happens through the bill/payment tools, never here (this tool is read-only). The result renders as a documents card listing the documents in the customer's UI — do NOT repeat the list in your reply. Answer with ONE short sentence (e.g. how many arrived and the most recent); if the user asked about one specific document, mention just that one.
Return coarse demographics for the authenticated user — age range, gender, postal-code prefix, language. Used by the agent at WebSocket-open time to enrich PII-sanitizer trace metadata. Plugins that don't implement this return `supported=false`.
Return the authenticated customer's display identity (name and email) so the agent can populate the live-agent CRM at handover time. Plugins that don't expose customer info return `supported=false`. Used by the handover_finalize node, not by the LLM directly.
Return the authenticated holder's segment — `retail` (individual) or `corporate` (company). Used by the agent at WebSocket-open time to tailor the assistant's suggested-prompt start screen to the customer. Plugins that don't distinguish the two return `supported=false`.
Search the bank's own knowledge base (products, fees, terms, policies, processes, branches/opening hours, FAQs) and answer ONLY from what it returns. Call this BEFORE answering any bank-specific factual or 'how do I…' question — never answer those from general knowledge. - The knowledge base is this bank's own material — you speak FOR the bank, in the first person plural ('við bjóðum …', 'hjá okkur …'). NEVER refer the customer to the bank or its website as if it were a third party — link the exact source page instead. - Catalog/overview questions ('hvaða reikninga/kort/lán eruð þið með?') need more than one search: run 2-3 searches with different phrasings (the category, then the specific product names seen in the first results) and synthesize a complete, structured answer — name each product found with one line on who it suits. - Ground every factual claim in the returned passages and cite sources as markdown links — inline or as a final 'Heimildir:' / 'Sources:' line with each result's [title](url). Every knowledge-base answer must carry at least one source link. - Rates, fees and other volatile figures: quote them only when a returned passage states the figure, and attach its as-of date ('miðað við DD.MM.YYYY', from the passage's effective_date). If the passages describe the product but NOT the figure asked for, do not present tables with the numbers missing — say plainly that the exact figure isn't in your material, link the product/price-list page where it lives, and offer to connect a human. For the customer's own balances/transactions use the account tools, never the knowledge base. - Many products exist in a personal (einstaklingar) and a business (fyrirtæki) version. Default to the personal version for a retail customer — never present the business version as the answer while claiming the personal one is unknown; search again with 'einstaklingar' if needed. - If the search returns nothing relevant (no results, or a recoverable code), do NOT answer from general knowledge. Say plainly — in the customer's language — that you do not find it in the bank's documents. ONLY IF a human-handover tool is available to you, offer to connect a human and call it with a reason that includes the customer's original question; if you have NO such tool, do NOT offer to connect anyone — instead point the customer to the bank's own service channels (þjónustuver / netspjall). Never guess an answer. - Do not pass the limit parameter — the server default returns the right amount of context. Your search queries may be phrased in any language, and retrieved passages may be in another language than the customer — always write the final answer in the language of the customer's message.
Ask the user a short multiple-choice question and let them pick by tapping a button — the chat input turns into one button per option (plus an automatic Cancel button), and the user's tap comes back as their next message. Use it when you are NOT certain how to proceed and must not guess: - a recipient name that matched SEVERAL saved recipients (one option per candidate, so the user picks which one); - which of the user's own accounts to pay from, when it is genuinely unclear; - any yes/no you need before moving money or creating something. For a name that matched NO saved recipient, do NOT use this tool — there is nothing to choose, you simply need their account number; ask for it as a normal chat message. Only ask when there is real doubt — when exactly one saved recipient clearly matches, just proceed. Pass a short `question` and 2-4 concrete `options` phrased as the choices themselves — say what each one does (e.g. 'Millifæra á **Jón Jónsson**', 'Millifæra á **Jón Pálsson**'), not bare 'Yes'/'No'. Do NOT add a Cancel/'Nei'/'Hætta við' option of your own — a Cancel button is always added for you, so a second one is a confusing duplicate. Bold the recipient or account name with **double asterisks** wherever you name it — in the question, the options, and your message; never use «French» quotes. Both `question` and `options` must be in the user's language. In Icelandic, decline the name correctly: as a label right after 'viðtakanda' or 'sem heitir', use the NOMINATIVE (dictionary) form — 'sem heitir **Vala**', NOT 'viðtakanda **Völu**'; after a preposition or verb, decline normally ('á **Völu**', 'til **Völu**', 'vista **Völu**'). The turn ends as soon as you call this tool, and the card already shows BOTH the question and the options — so do NOT also write them as a chat message; say nothing else on that turn. After the user replies, act on their choice; if they cancel, acknowledge briefly and stop — do not move money.
Get the corporate account holder's profile: company name, kennitala, VAT number (VSK-númer), legal form (rekstrarform), and the list of users with their roles, signing authority (prókúra) and approval limits (heimildir). Use when the user asks about the company itself, who can approve payments, who holds prókúra, or the team's access rights. Identity and people only — balances and financials are get-corporate-position. Company/corporate accounts only.
Get the company's financial position at a glance, as it stands right now: ISK account balances and available funds, outstanding receivables (útistandandi kröfur) total, upcoming tax obligations, and how many payment batches are pending. Use for 'how are we doing', 'staðan', overall company position, or total balances. This is the CURRENT snapshot — for how the position has developed over time use get-balance-history, and for a forward liquidity projection use get-cashflow-forecast. The totals are already aggregated — do not sum accounts by hand; for the per-account list with account numbers and IBANs use get-accounts. Company/corporate accounts only.
List the company's issued claims / receivables (kröfur — the company as kröfuhafi / creditor), with payer, amount, due date (gjalddagi) and status. Use for 'our claims', 'útistandandi kröfur', who owes us, or overdue invoices. Optionally filter by status, or set overdue_only=true to return only claims past their final due date (eindagi). These are receivables owed TO the company — bills it must PAY are get-unpaid-bills. Company/corporate accounts only.
Look up a single issued claim (krafa) by its claim number (kröfunúmer). Use when the user references a specific claim/invoice number. Company/corporate accounts only.
List the company's payment batches (greiðslubunkar) with type, status, line count and total amount. Use for 'our payment batches', 'greiðslubunkar', recent or pending outgoing payment runs — and for 'hvað þarf ég að samþykkja' / what awaits sign-off: status 'awaiting_approval' means a batch still needs its one approval, 'approved' means it is approved and ready to pay. Optionally filter by status (draft / awaiting_approval / approved / completed). The agent never approves — an authorized user (prókúra / samþykktarheimild) approves and pays in the bank's own netbanki. For one batch's payee lines and approval detail use get-payment-batch. Read-only: to SET UP new outgoing payments (refunds, payouts, a pasted greiðsluskrá) use create-payment-batch. Company/corporate accounts only.
Get one payment batch (greiðslubunki) in full: its payee lines and its live approval state — whether it still needs its one approval or already has it, and any rejection. Use to inspect a specific batch before discussing it. The agent never approves — an authorized user (prókúra / samþykktarheimild) approves and pays it in the bank's own netbanki. If the user names a batch instead of giving its id (e.g. 'open the Stórgreiðsla batch'), first call list-payment-batches, match the name, and pass that batch's id here — never ask the user for the id. Company/corporate accounts only.
List the company's PAST payroll runs (launakeyrslur) — read-only history with pay date, gross and net totals, withholding (staðgreiðsla), pension (lífeyrir) and employee count. Use for what payroll cost, 'hvað borguðum við í laun', or a past launakeyrsla. NOT for running payroll — 'keyrðu launin' / 'stofnaðu launakeyrslu' is create-payroll-run — and NOT for whether the company can afford upcoming payroll, which is get-cashflow-forecast. Company/corporate accounts only.
List the public charges (opinber gjöld) the company owes and must pay: VAT (VSK), withholding (staðgreiðsla), payroll tax (tryggingagjald) and similar levies, with amount and due date. These are payables — treat them as part of what the company owes alongside its supplier bills (get-unpaid-bills), not a separate tax-advice domain. Use for 'hvað skuldum við í VSK', opinber gjöld, or upcoming public-charge due dates. Company/corporate accounts only.
Get the bank's current foreign-exchange rates against ISK (gengi gjaldmiðla). Use for 'exchange rate', 'gengi', 'hvað kostar evran', or before discussing a currency purchase. Company/corporate accounts only.
Get the company's foreign-currency exposure: FX account balances, recent spot trades (gjaldeyrisviðskipti) and outstanding forward contracts (framvirkir samningar). Use for 'how much do we hold in EUR/USD', 'gjaldeyrisstaða', or FX/forward questions. Company/corporate accounts only.
Project the company's liquidity forward over a horizon: current ISK liquidity, expected inflows (claims due, kröfur á gjalddaga), committed outflows (pending payment batches + taxes due) and the projected balance. Use for 'cashflow', 'lausafjárstaða', 'will we have enough to cover X' / 'eigum við fyrir launum/VSK/reikningunum', 'what's due in the next two weeks', or liquidity/runway questions (affordability of UPCOMING payroll and taxes lives here, not in the payroll or tax listing tools). This is the forward-looking view; get-corporate-position is the position now and get-balance-history is how it developed in the past. The numbers are already aggregated — do not compute the forecast by hand (get-accounts shows only current balances, not projected inflows/outflows). Company/corporate accounts only.
Get the company's total-position history: month-end snapshots of the whole position over time — total deposits, total loans (negative) and the net position (heildarstaða), each in ISK with any foreign-currency balances converted at the bank's rates. Use when the user asks how the company's overall position or balances have developed over the year, about trends in heildareignir / heildarstaða, or to chart total balances over time. Pass months to widen or narrow the window (1–36 month-ends, default 13). get-corporate-position is the CURRENT snapshot; this is the time series behind it, and get-cashflow-forecast is the forward projection. The series is already aggregated and FX-converted — do not sum accounts by hand. Company/corporate accounts only.
Look up a kennitala in the national registry (þjóðskrá): its registered name and whether it is a company or an individual (entity_type). Use when the user gives a kennitala and needs the name behind it, or to verify who a payee/payer is before acting. Returns code 'not_found' for a well-formed kennitala that is not on the registry. This is a SINGLE lookup: batch and claim creation already resolve every line's name from þjóðskrá by its kennitala automatically, so do NOT call this once per row of a pasted greiðsluskrá / payment file. Company/corporate accounts only.
List the bank-account products the company can open by itself: current (veltureikningur), savings (vaxtareikningur — with/without binding or CPI indexing), term-deposit (fastvaxtareikningur) and currency (gjaldeyrisreikningur) accounts, each with its interest rate and binding terms. Use when the user asks what accounts/savings options they can open, about deposit interest, or before opening one. Company/corporate accounts only.
Prepare a money transfer for the user to confirm (AI-executes mode: prepare → the user confirms → execute-transfer). Pass the recipient as plain values — do NOT build a typed creditor object. Domestic Icelandic transfer is the default. Do this every time, in order: (1) Recipient — when the user names one (e.g. 'millifærðu á Tryggva'), FIRST call get-recipients with the name in nominative form, then act on the result: exactly one match → prepare with THAT recipient (it is already saved, so do NOT call create-recipient); several matches → ask which one before preparing; no match → ask for the recipient's account number as a normal chat message and prepare the transfer to the number they give you. (As a safety net this tool also resolves a bare recipient_name itself and may return missing_recipient / ambiguous_recipient — handle those the same way, but prefer the explicit get-recipients step so the customer sees the lookup happen.) (2) Source account — from_account_id is one of the USER's OWN accounts: the Account.id (a UUID) from get-accounts, NEVER an account number and NEVER the recipient's account. When the user did not name a source account, omit it to use their default withdrawal account (normally the Tékkareikningur); only ask which account to pay from if there is genuine ambiguity. (3) Call this tool once. After it succeeds the user sees a transfer card with the amount and accounts and a 'Millifæra' button; they confirm by tapping it or replying. Your message MUST match this flow — you prepared a millifærsla (transfer), NOT a greiðslufyrirmæli: say 'Ég útbjó millifærslu upp á 2.000 kr. til Gunnu — farðu yfir hana og smelltu á 'Millifæra' til að staðfesta.' / 'I've prepared a transfer of 2,000 kr to Gunna — review it and tap 'Millifæra' to confirm.' Do NOT say 'greiðslufyrirmæli' / 'payment order' and do NOT mention 'Klára greiðsluna núna' — that wording belongs only to bank-authorised mode — and do NOT claim the money was already sent: it moves only when you call execute-transfer with the transferIntentId after the user confirms. execute-transfer's response for a NEW recipient (account number typed by the user, not from get-recipients) already ends with the save-recipient offer — relay it, do not add your own; if the user accepts, call create-recipient.
Prepare a bill payment for confirmation. Validates the bill exists, isn't already settled, and that the chosen source account has enough funds. Returns the prepared payment — always confirm the bill, the amount, and the source account with the user, and only call execute-bill-payment after they explicitly confirm.
Execute a bill (krafa) payment after the user has confirmed. Use pay-bill first to prepare and validate, then call this tool once the user explicitly approves.
Save a new recipient (viðtakandi) to the user's recipient list — the 'Vista viðtakanda' checkbox on Icelandic bank forms — so they can just say the name on future transfers. NEVER call this automatically: only with the user's explicit consent, and only AFTER the money has moved. Saving is an optional afterthought, NEVER a precondition for a transfer or payment order — never offer it as the way forward when a name matches no saved recipient (the user can pay someone once without ever saving them). The money-movement tools already end their response with the save offer when the recipient is NEW (account number typed by the user rather than returned by get-recipients) — relay that offer as-is, do not add a second one. Skip any save offer entirely when get-recipients matched the recipient earlier in this conversation, or you already saved them this conversation — never ask twice for the same recipient, and never nudge again after a decline ('nei', 'ekki núna'): the money already moved, so drop the subject and never re-issue the order/transfer. When the user accepts: call this tool with the display name they picked (often informal — 'Pabbi', 'Leigan' — or a full name; in Icelandic save the label in NOMINATIVE form, e.g. **Valgerður**, even though the name declines after verbs: 'vista **Valgerði**') and the same account number you just used for the order or transfer, plus the kennitala if known. Do NOT construct a typed identifier object — pass the account number as a plain string. Then confirm in one line ('Gert — **<Name>** er komin á viðtakendalistann.').
This example shows how the Agent communicates with MCP Server. User tokens come from httpOnly cookies.