Model Context Protocol
Your agent. Your data. Read-only.
Verdia speaks the Model Context Protocol, so the AI assistant you already use can read your own figures: balances, the thirteen-week forecast, what is covered and what is not. You grant it three things separately, you see every one of them listed in Settings, and you can take any of them back in one click.
Endpoint
https://verdiabank.com/api/mcp
Streamable HTTP, specification revision 2026-07-28. A personal access token goes in an Authorization: Bearer header; POST is the only method the endpoint answers.
Three scopes, granted separately
accounts:read
Tools
list_accounts, get_balance
Account names, the last four characters of each account number, and balances. The full number is never sent, to an agent or to anyone else.
cashflow:read
Tools
get_forecast, get_coverage, get_recurring, get_anomalies
The thirteen-week forecast, whether the next payroll and the next VAT payment are covered by the balance projected for the day they fall due, what repeats on a rhythm, and what looks wrong.
insights:read
Tools
get_insights
The plain-language sentences your own Insights page shows, in the same order of urgency, written from the same numbers.
Nothing here writes
There is no tool that moves money, pays an invoice, changes a status or sends a message, and there will not be one in this version. Every tool is a read of something already on your own dashboard. An agent connected to Verdia can tell you that payroll is short on the 25th; it cannot do anything about it.
Why not bring your own model key
The obvious alternative is to let you paste an API key of your own into Verdia. We decided against it: it would make us the custodian of someone else's billable credential, it would make a wrong answer impossible for either of us to debug, and it asks you to make a choice you have no way to evaluate. This is the inverse. We keep our own model arrangement for what we write; your agent keeps yours, and reads your data through a door you opened.
How to create a token
Sign in to the preview, open Settings, and look for Agent access. Name the token after the place it will live, tick what it may read, choose how long it should last, and copy it once — we store only a hash, so we cannot show it to you again. Paste it into your agent as the bearer token for this endpoint.
If one leaks
Revoke it in Settings; it stops working on the next request. A token reads one company and expires on its own after 30, 90 or 365 days, whichever you chose. Every use is in our audit log, so we can tell you what was read and when.
About authorisation
The specification's answer for a remote server is OAuth 2.1. We have deliberately not built an authorisation server for this first version: it is a consent surface and a client registry of its own, and it would sit on a BankID session that idles out after fifteen minutes. A token you create yourself, scoped and expiring, is the smaller and more honest thing to ship first.