openbanking-mcp — Konten lesen und VORHER warnen
Das Repository heißt
openbanking-mcp, der Befehl heißtbankread. Das ist keine Unachtsamkeit: Der Name des Repositorys sagt, was es ist – ein MCP-Server über Open Banking –, weil man es so findet. Der Name des Befehls sagt, was man damit tut, undbankread doctorlässt sich leichter eintippen alsopenbanking-mcp doctor. Die Konfigurationspfade (~/.config/bankread, Schlüsselbundbankread-enablebanking) folgen dem Befehl, nicht dem Repository.
Nur-Lesezugriff auf Bankkonten per PSD2 (AIS-Zulassung), plus ein tägliches Briefing für Todoist. Python 3.11+, keine Drittanbieter-Abhängigkeiten: urllib für HTTP, handgeschriebenes JSON-RPC für den MCP-Server. Läuft auf dem Mac, nicht in einer Cloud.
⚠ Der Datenanbieter muss gewählt werden – vor dem Start lesen
Dieses Repository entstand mit einem GoCardless Bank Account Data-Client (ehemals Nordigen), der der offensichtliche kostenlose Weg war. Stand 2026-08-20: Dieser Dienst ist für Neuanmeldungen geschlossen und wird eingestellt.
bankreadlib/gocardless.pydient daher nur noch denen, die bereits ein Konto hatten.Der kostenlose Ersatz für den persönlichen Gebrauch ist Enable Banking, dessen Stufe Restricted Production echte Produktionsdaten nur für die Konten liefert, die man selbst anbindet – was genau der Verwendungszweck hier ist, und ohne zu zahlende Lizenz. Der Enable-Banking-Client ist geschrieben (
bankreadlib/enablebanking.py): Selbstbedienungs-Registrierung per E-Mail, Authentifizierung per signiertem JWT RS256 – ohne Abhängigkeiten, die Standardbibliothek reicht (bankreadlib/rs256.py). Der Überblick über die praktikablen Lösungen für BoursoBank und die drei Entdeckungen, die den Code verändert haben, finden sich indocs/fournisseurs.md.Es bleibt eine Sache, die niemand für dich tun kann: das Enable-Banking-Konto erstellen, dort deine Bankkonten angeben und die Einwilligung unterschreiben. Anwendungs-ID und privater Schlüssel sind persönlich – es gibt nichts zu teilen, und genau dort muss man anfangen.
Alles andere im Repository ist anbieterunabhängig.
BoursoBank sendet bereits „Ihr Kontostand ist niedrig“. Die Caisse d'Épargne sendet bereits „Geldeingang“. Amazon sendet „in Lieferung“, Leboncoin „der Verkäufer hat bestätigt“. Die Information kommt bereits – sie kommt nur zu spät und am falschen Ort.
zu spät: Ein Schwellenwert-Alarm wird NACH der Abbuchung ausgelöst. Am Morgen des 15. sind die Steuern abgebucht, das Konto ist niedrig, und der Alarm stellt es nur fest;
am falschen Ort: mitten unter zweihundert E-Mails, von denen die meisten nicht gelesen werden.
Dieses Projekt sucht also keine fehlende Information. Es tut das Einzige, was niemand tut: die Subtraktion. Den heutigen Kontostand minus das, was bis zum Monatsende anfällt. Weder die Bank noch die Steuerbehörde kann das tun – keiner von beiden sieht den anderen.
Was es nicht löst: Nichts hier ersetzt den Blick auf die eigenen Konten. Eine neue, nie gesehene Abbuchung bleibt für einen Wiederholungserkenner unsichtbar.
Related MCP server: pocketledger
Die Verbindung läuft über die PSD2/AIS-Zulassung des Anbieters (Enable Banking, kostenlose Stufe Restricted Production). AIS ist das Zusammenführen von Kontoinformationen. Die Zahlungsauslösung ist eine separate Zulassung (PIS), die dieses Token nicht hat und die die Bank ihm nicht gewähren wird. Das schlimmste Szenario bei einem Datenleck ist das Lesen eines Verlaufs, niemals eine Geldbewegung. Das ist der einzige Grund, warum dieses Projekt existieren darf.
Drei praktische Konsequenzen:
Die Anbieter-Zugangsdaten liegen im macOS-Schlüsselbund, nicht in einer Datei – eine Datei landet in einem Backup-Tar, einem unglücklichen cat, einem rsync zu einem NAS. Für Enable Banking gehört dazu der private RSA-Schlüssel: bankread secrets --set liest ihn, verstaut ihn und erinnert daran, die heruntergeladene .pem-Datei zu löschen;
Die Bankeinwilligung läuft ab – drei bis sechs Monate, je nachdem, was die Bank gewährt, und gespeichert wird ihre Antwort, nicht unsere Anfrage. Nichts kann sie für dich erneuern: Du musst auf die Website deiner Bank zurückkehren. doctor warnt 14 Tage im Voraus (nicht 1 Tag im Voraus, wo ein Wochenende genügen würde, um alles verfallen zu lassen);
Das alles läuft auf dem Mac. Nicht in einer Cloud-Sitzung, nicht in einem Container.
./bankread demoEin erfundenes Konto, 400 Tage erfundener Verlauf, ein imaginärer Kontostand – und die echte Erkennung und die echte Prognose, die darauf laufen. Nichts wird außerhalb eines temporären Verzeichnisses geschrieben.
Was die Demonstration zeigt und worum es eigentlich geht:
2026-08-23 ±3j -890.00 → 394.55 Loyer … [loyer]
2026-08-25 ±3j -412.00 → -17.45 Dgfip Impot … [impots]
2026-08-29 ±3j 2450.00 → 2432.55 Salaire …
⚠ passe sous 300 € le 2026-08-25 (-17.45 €), poussé par « Dgfip Impot Revenu »
(1 motif(s) incertain(s) non comptés — la vraie trajectoire peut être plus basse)Die Miete lässt den Kontostand noch über der Untergrenze; es sind die Steuern, die ihn darunter fallen lassen, fünf Tage vor dem Gehalt. Deine Bank wird es am Morgen des 25. sagen. Und die letzte Zeile ist die wichtigste: Die Grundsteuer ist im Verlauf nur zweimal vorgekommen, also wird ihr nicht geglaubt, also zählt sie nicht – und die Prognose kündigt selbst an, dass sie optimistisch ist, statt so zu tun, als ob.
Drei Möglichkeiten, in der Reihenfolge der Verbindlichkeit, die sie verlangen:
git clone https://github.com/Beennnn/openbanking-mcp && cd openbanking-mcp && ./bankread doctor
uvx --from git+https://github.com/Beennnn/openbanking-mcp bankread doctor # sans rien installer
pipx install git+https://github.com/Beennnn/openbanking-mcp # à demeureDas Klonen zuerst, und nicht aus Gewohnheit: Ein Werkzeug, das Bankkonten liest, wird gelesen, bevor man es installiert. ./bankread funktioniert direkt aus dem Klon, ganz ohne etwas zu installieren.
# 0. créer l'application chez le fournisseur : https://enablebanking.com/sign-in/
# Control Panel → API applications → environnement « Production », clé générée.
# L'URL de retour à déclarer est http://127.0.0.1:8788/callback (à l'identique).
# 1. les deux identifiants (le second est le CHEMIN du .pem téléchargé)
bankread secrets --set # ils vont dans le trousseau, pas sur le disque
# 2. trouver sa banque, puis signer le consentement (ouvre le site de la banque)
bankread banks bourso # relève le NOM EXACT que renvoie l'API
bankread link "BoursoBank" # puis, séparément :
bankread link "Caisse d'Epargne"
# 3. vérifier
bankread doctor
bankread project --days 45 --floor 300
# 4. le brief de 7 h 30 → tâches Todoist
launchd/install.sh
launchctl kickstart -k "gui/$(id -u)/com.bankread.brief-quotidien" # essai immédiatDas ist die Bank, für die dieses Repository geschrieben wurde, also erfährst du hier, was dich erwartet, statt einer Allgemeinheit. Eine andere Bank wird sich anders verhalten – und maßgeblich ist bankread banks, nicht diese Datei:
~90 Tage Verlauf, nicht mehr. Die MONATLICHEN Fälligkeiten – Miete, EDF, monatliche Steuerabbuchung – erscheinen schon bei der ersten Abfrage: Drei Durchgänge genügen. Die jährlichen warten, bis das Register angesammelt hat (siehe oben).
Die Freigabe erfolgt über die BoursoBank-App (starke PSD2-Authentifizierung). Der Ablauf bankread link öffnet die Website, dann klingelt das Telefon. Man muss es also griffbereit haben und diese Aktion alle 90 Tage wiederholen.
Nicht auf die Wicount-360-Aggregation zählen. BoursoBank aggregiert bereits das Konto der Caisse d'Épargne und sendet Warnungen dazu, aber PSD2 gewährt Zugriff auf die Konten, die bei der angefragten Bank geführt werden, nicht auf das, was sie von anderswo aggregiert. Das Konto der Caisse d'Épargne erfordert daher ein eigenes bankread link mit eigener 90-Tage-Einwilligung. (Beim ersten Anschluss zu bestätigen: Falls die externen Konten im Ablauf erscheinen, umso besser.)
Gemeinschaftskonten werden im Einwilligungsbildschirm der Bank ausgewählt. Nur ankreuzen, was man wirklich lesen möchte: Was angekreuzt ist, wandert ins lokale Register, und das Register vergisst nichts.
bankread banks bourso liefert den genauen Namen – bei Enable Banking wird eine Bank über ihren NAMEN und ihr Land bezeichnet, nicht über eine technische Kennung – und die maximale Einwilligungsdauer, die diese Bank gewährt. Dieser Wert ist maßgeblich, nicht diese Datei.
link schließt automatisch den Abruf des goldenen Zeitfensters an: Der vollständige Verlauf wird nur innerhalb der Stunde nach der Unterzeichnung ausgeliefert, danach fällt die Bank wieder auf 90 rollierende Tage zurück. Diesen Schritt nicht unterbrechen – er wird erst bei der nächsten Verlängerung in drei bis sechs Monaten wieder ausgeführt.
| was funktioniert, was wann kaputtgeht. Kein Netzwerkaufruf – eine Diagnose, die Kontingent verbraucht, ist eine Diagnose, die man nicht zu starten wagt. |
| die Kontostände mit ihrem Alter |
| die erkannten Fälligkeiten und ihr nächster Termin |
| die Kreuzung: Kontostand minus anstehende Fälligkeiten, Tag für Tag |
| die letzten Buchungen |
| alles auf einmal, für ein Skript |
| das Ergebnis auf einem FIKTIVEN Konto – ohne Bank, ohne Anmeldung |
| MCP-Server über stdio, sechs Lese-Werkzeuge – für Claude oder jeden anderen MCP-Client |
Exit-Codes: 0 alles in Ordnung, 1 es gibt etwas zu prüfen, 2 harter Fehler – damit launchd und die aufrufenden Skripte sich zurechtfinden.
claude mcp add bankread -s user -- "$PWD/bankread" mcpOder ganz ohne Klon, wie jeder MCP-Server verteilt wird:
{
"mcpServers": {
"bankread": {
"command": "uvx",
"args": ["--from", "git+https://github.com/Beennnn/openbanking-mcp", "bankread", "mcp"]
}
}
}MCP ist ein offenes Protokoll, und bankreadlib/mcp.py ist handgeschriebenes JSON-RPC: keine Hersteller-Bibliothek, kein Token, kein ausgehender Aufruf. Derselbe Server wird in den anderen MCP-Clients auf dieselbe Weise deklariert, und bankread json bedient diejenigen, die es nicht sind. Das alles – einschließlich der Frage, wie man es komplett weglässt – steht in docs/integration.md.
Vier Aufrufe pro Tag und pro Konto. Die meisten Banken begrenzen den im Hintergrund durchgeführten Abruf auf vier Aufrufe pro Konto und Tag. Vier. Das ist keine Grenze, die man streift, sondern eine, die man an einem Vormittag beim Debugging erreicht. Daher ein Cache, der kein Komfort ist: Ohne ihn schlägt das morgendliche Briefing jeden zweiten Tag fehl. Daher auch --refresh, das explizit ist und nie die Standardeinstellung.
Die Obergrenze entfällt, wenn ein Nutzer tatsächlich vor dem Bildschirm sitzt, was ein PSU-Header der Bank mitteilt. bankread sendet ihn nur, wenn der Befehl ein Terminal hat: Das Briefing um 7:30 Uhr hat keins, bleibt also gedeckelt. Das ist eine Angabe gegenüber einer Bank, keine Leistungseinstellung – sie von einem launchd-Agenten auf „wahr“ zu setzen, wäre eine Lüge.
Ein kurzer Verlauf macht eine Prognose OPTIMISTISCH, nicht unvollständig. Nicht alle Banken geben dreizehn Monate heraus – BoursoBank gibt etwa 90 Tage heraus. Unterhalb von 380 Tagen konnte eine jährliche Fälligkeit (Grundsteuer, Versicherung, Abgabe) nicht zweimal gesehen werden, also existiert sie für den Erkerner nicht, also ist die angekündigte Entwicklung besser als die wahre. Das ist die einzige Stelle, an der ein Irrtum Geld kostet, deshalb sagen upcoming, project und doctor es unmissverständlich.
Und vor allem deshalb ledger.py sammelt, statt zu cachen. Der
erste Entwurf (2026-08-20, morgens) behielt eine Momentaufnahme: Jede Lesung ersetzte die
vorherige. Bei einer Bank mit 90 Tagen machte das eine jährliche Fälligkeit nicht
„noch nicht erkannt“, sondern lebenslang unerkennbar — alles, was das Quartal überstieg,
verschwand aus der API und dem Cache gleichzeitig. Das Register schmilzt jede Lesung in
eine dauerhafte Datei; nach einem Jahr voller Briefings kennt bankread 365 Tage, wo die
Bank nur 90 zeigt, und die Grundsteuer erscheint beim zweiten Durchgang.
bankread doctor zeigt den Countdown an.
Keine grüne Zeile, die nicht beobachtet wurde.
Jede Antwort von read.py trägt ein Feld etat:
| was es bedeutet |
| gerade gelesen, oder neu genug, um noch wahr zu sein |
| aus dem Cache serviert, mit klarem Alter — zu lesen, nicht zu glauben |
| wir haben nichts Frisches genug, um irgendetwas zu behaupten |
Nie ein nackter Kontostand. Ein solde: null, etat: "inconnu" ist kein Nullkonto, und
es ist die schlechteste mögliche Lesart einer fehlenden Zahl — die Beschreibungen der MCP-Tools
wiederholen es dem Modell, bevor es aufruft, damit es es nicht falsch lernt.
Dieselbe Disziplin bei Vorhersagen: Eine Fälligkeit, die zweimal gesehen wurde, ist keine Fälligkeit,
es ist ein Zufall. Sie wird mit confidence: "faible" markiert und fließt nicht in die
Projektion ein. Drei regelmäßige Durchgänge, das ist eine Tatsache.
Und bei Einnahmen: Nur die Ausgaben zu projizieren ergibt eine Flugbahn, die immer
abstürzt, also einen Alarm jeden Tag, also nach einer Woche gar keinen Alarm mehr.
Das Gehalt und die Zuschüsse werden über denselben Pfad erkannt und gezählt, nur in die
andere Richtung. test_le_salaire_qui_arrive_avant_evite_la_fausse_alerte deckt diesen Fall ab.
brief/brief.md ist der Text, den Claude jeden Morgen ausführt, gestartet von launchd über
brief/run-brief. Es liest Gmail und die Bank, und seine einzige sinnvolle Ausgabe ist eine kleine
Anzahl von Todoist-Aufgaben, markiert mit auto-brief.
Stille ist ein Erfolg. Ein Morgen ohne etwas zu melden erzeugt null Aufgaben — keine
tägliche Zusammenfassung, kein „nichts zu melden“. Nur fünf Muster erzeugen eine Aufgabe,
und die Datei ~/.config/bankread/brief-vu.json verhindert, dass dasselbe verspätete Paket
mehr als einmal pro Woche eine erzeugt.
run-brief übergibt eine GESCHLOSSENE Liste von Werkzeugen an claude --allowedTools. Kein Werkzeug
zum Schreiben in Gmail ist darin: Das Briefing liest die Post, es antwortet nie. Und nichts
ist einer Autorisierungsanfrage überlassen, da niemand vor dem Bildschirm sitzt, um um
7:30 Uhr zu antworten.
Das aufgerufene Modell ist ein austauschbarer Pilot (brief/agents/), kein fest verdrahteter Aufruf:
BANKREAD_AGENT=aucun brief/run-brief lässt das Briefing ohne jede KI laufen, und die
Projektion landet trotzdem im Journal. Das Lesen der Konten brauchte nie
ein Modell — siehe docs/integration.md.
launchd/install.sh installiert nur diesen Agenten. Ein Installationsskript, das mehr
tut als sein Name, endet damit, etwas Totes neu zu installieren, und man verbringt den Abend damit,
zu suchen, warum zwei Exemplare laufen.
Die Kopplung ist dünn, und das ist durch einen Test abgesichert (test_le_contrat_tient_en_deux_methodes) :
hängt vom Anbieter ab ? | |
| ja — Token, Kontingente, HTTP, Zustimmungspfade |
| er wählt aus, welchen er lädt, und schreibt den Vertrag in |
| ja, teilweise — der Verbindungspfad |
| nein, und kein einziger direkter Import mehr |
Um einen dritten Anbieter anzubinden, genügt ein Modul, das diese beiden
Methoden bereitstellt — das Protocol von provider.py deklariert sie, und provider.charger() übernimmt die
Auswahl:
balances(account_id) -> {"balances": [...]}
transactions(account_id, date_from, date_to) -> {"transactions": {"booked": [...]}}Das erwartete Format ist das der Berlin-Gruppe : balanceType / balanceAmount für
die Salden, bookingDate und transactionAmount signiert für die Buchungen. Wenn der
Anbieter etwas anderes spricht, zahlt der Client die Übersetzung und sonst niemand —
siehe enablebanking._operation(), die den Beträgen ihr Vorzeichen zurückgibt,
während Enable Banking sie immer positiv liefert.
Drei Fallstricke, die man beim Schreiben des Enable-Banking-Clients entdeckt und nicht wiederholen sollte:
das Vorzeichen der Beträge steht neben dem Betrag (credit_debit_indicator), nicht
darin. Es einfach zu übernehmen würde jede Lastschrift wie eine Gutschrift zählen;
der vollständige Verlauf dauert nur eine Stunde nach der Unterzeichnung (siehe oben) ;
die Dauer der erteilten Zustimmung kann kürzer sein als die angefragte: Das ist
die Antwort der Bank, die man speichert, sonst meldet doctor eine gültige Zustimmung
zwei Monate nach ihrem Ablauf.
python3 test_bankread.py51 Tests, nur Standardbibliothek, kein Netzwerk. Sie prüfen vor allem die Fälle, in denen der Code schweigen muss : Zwei Vorkommen ergeben keine Fälligkeit, ein Cache von dreißig Stunden ist kein Saldo, man projiziert nicht auf einen nie beobachteten Saldo. Eine Erkennung, die sich beim Datum irrt, stürzt nicht ab — sie meldet die Steuern am 12. statt am 15., mit derselben Gelassenheit.
~/.config/bankread/state.json (verbundene Konten, Token, Zustimmungsdaten) und
~/.cache/bankread/ — spezifisch für diese Maschine und diese Zustimmung. Die Identifikatoren
des Anbieters sind nirgends auf der Platte: Sie liegen im macOS-Schlüsselbund,
Dienst bankread-enablebanking (oder bankread-gocardless), privater RSA-Schlüssel inbegriffen.
⚠️ ~/.local/share/bankread/ledger/ ist etwas anderes: Es ist das Register, und es wird nicht
gelöscht. Was es enthält, kann die Bank nicht mehr zurückgeben — nach 90 Tagen hat sie
es vergessen. Es zusammen mit dem Cache zu löschen heißt, mit drei Monaten Gedächtnis neu zu starten. Es ist
unter den Daten und nicht im Cache abgelegt, genau um diese Verwechslung
schwierig zu machen. Akzeptierte Kehrseite: Es ist ein Jahr Banktransaktionen im Klartext auf der
Platte, mit Berechtigung 0600.
La liste des comptes liés, leur banque et l'état de leur consentement.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the output contents. It does not mention read-only behavior, required authentication, possible empty results, or any side effects, leaving significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states the tool's output. Every word contributes to the purpose, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only listing tool, the description is reasonably complete: it names the returned entity and key fields. It could be slightly richer by noting when this list is meaningful or how consent state is represented, but the low complexity makes this sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is fully described, so parameter-level documentation is unnecessary. The baseline of 4 applies because there is nothing for the description to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning the list of linked accounts, their bank, and consent status, which differentiates it from siblings like soldes, transactions, or projection. However, it lacks an explicit action verb such as 'List' or 'Retrieve', relying on the noun phrase 'La liste' to convey the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus the sibling tools. The intended use is only implied by the word 'comptes', so an agent receives no clear context for selection or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Les opérations qui reviennent (prélèvements ET rentrées), détectées sur l'historique : cadence, montant médian, date du prochain passage. Chacune porte confidence : "sure" (≥3 passages réguliers) ou "faible" (2 passages — une coïncidence possible, à ne pas annoncer comme un fait). annuel_detectable dit si l'historique remonte assez loin pour qu'une échéance annuelle ait pu être vue passer deux fois ; s'il est faux, l'absence de taxe foncière ne prouve RIEN et toute projection est optimiste — le dire, plutôt que conclure que tout va bien. jours_avant_annuel_detectable donne le délai : la banque ne rend que ~90 jours, mais bankread accumule localement, donc ce nombre descend tout seul à chaque lecture.
| Name | Required | Description | Default |
|---|---|---|---|
| compte | No | Identifiant du compte. Omis : le premier compte lié. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses confidence thresholds ('sure' ≥3 passages, 'faible' for 2), explains that low confidence should not be announced as fact, details the annual detectability limitation (absence of tax foncière proves nothing if history is too short), and notes that bankread accumulates locally extending the ~90-day bank window. This is rich behavioral context beyond basic functioning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured: it opens with the main output, then explains confidence levels, annual detection, and local accumulation in separate clauses. Every sentence adds value, but the technical details make it somewhat long. It is appropriately sized for the complexity without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must convey the return structure. It mentions all key fields (cadence, montant médian, date du prochain passage) and specific metadata (confidence, annuel_detectable, jours_avant_annuel_detectable). It lacks an explicit field list or error conditions, but given the single input parameter and straightforward purpose, the description is sufficiently complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter, which is self-explanatory ('Identifiant du compte. Omis : le premier compte lié.'). The description adds no additional parameter details, but does not need to since the schema already covers it. Baseline 3 is appropriate for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's function: detecting recurring operations (both debits and credits) from history and providing cadence, median amount, and next occurrence date. This is a specific verb+resource (detect recurring operations) and clearly distinguishes it from siblings like transactions or projection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you need recurring operation detection) and adds context about historical depth limits. It does not explicitly name alternatives or exclusions, but the sibling tools are distinct enough that this purpose is unambiguous. A clear context is present without explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
LE croisement : solde d'aujourd'hui moins les échéances sûres à venir, déroulé jour par jour. Rend franchissement (quand le solde passe sous le plancher, et quelle échéance l'y pousse), point_bas et le détail des mouvements. C'est ce qui répond à « est-ce que ça passe avant la fin du mois », là où une alerte de seuil bancaire n'avertit qu'après coup. Refuse de projeter sur un solde non observé plutôt que d'inventer une date.
| Name | Required | Description | Default |
|---|---|---|---|
| jours | No | Fenêtre de projection en jours (défaut 45). | |
| compte | No | Identifiant du compte. Omis : le premier compte lié. | |
| plancher | No | Seuil sous lequel alerter, en euros (défaut 0). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It adds meaningful behavioral detail: the projection is day-by-day, returns specific computed fields, and refuses to project on an unobserved balance rather than fabricate a date. It does not discuss errors, side effects, or permissions, but the read-only projection behavior is well conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with the core concept and no filler. Every sentence adds value: computation, outputs, use case/alternative, and a refusal edge case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain return values; it names the key outputs and covers the main edge case. It could be slightly more explicit about the `point_bas` result and exact output shape, but it is sufficient for a small projection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds useful semantic context by explaining the computation ('today's balance minus certain upcoming due dates, day by day') and the notion of the floor (`franchissement` when balance drops below it), which enriches the schema's minimal field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a projection tool: it crosses today's balance with upcoming certain due dates and rolls it out day by day. It names concrete outputs (`franchissement`, `point_bas`, movement details) and distinguishes itself from an after-the-fact bank threshold alert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use it: to answer 'will it pass before the end of the month.' It also contrasts itself with a threshold alert that only warns after the fact, though it does not name sibling tools or describe exclusion cases beyond that contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
État du lien bancaire : secrets présents, comptes liés, jours restants avant expiration du consentement DSP2, quotas d'appels, et registres — la profondeur d'historique réellement accumulée par compte, qui est supérieure à ce que la banque rend aujourd'hui. Aucun appel réseau, donc gratuit en quota. À appeler en premier quand quelque chose paraît manquer, et une fois par semaine pour voir venir le renouvellement à 90 j.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It discloses that the tool makes no network call ('Aucun appel réseau, donc gratuit en quota') and that 'registres' contains more history than the bank actually returns. This is valuable, though it doesn't explicitly describe side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it front-loads the purpose, lists contents, then provides usage guidance. Every sentence contributes meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter inspection tool with no output schema, the description fully covers what the tool returns and when to invoke it, including the important nuance about 'registres' and the weekly renewal check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing to explain. The description adds context about what the tool reports, which is sufficient given the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides an overview of the bank link status, enumerating specific contents (secrets, linked accounts, consent expiry, quotas, registres). This distinguishes it from sibling tools that fetch specific data like transactions or balances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is given: 'À appeler en premier quand quelque chose paraît manquer, et une fois par semaine pour voir venir le renouvellement à 90 j.' It also notes that it makes no network call and is free in quota, helping the agent decide when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Le solde disponible de chaque compte (interimAvailable : opérations en cours déduites). Toute réponse porte etat : "observe" (lu à l'instant), "ancien" (servi du cache, voir age_lisible) ou "inconnu" (rien de fiable — ne jamais présenter cela comme un solde nul ou une panne). Le quota est de 4 lectures par jour et par compte : laisser rafraichir à faux sauf demande explicite d'un chiffre à la seconde.
| Name | Required | Description | Default |
|---|---|---|---|
| compte | No | Identifiant du compte. Omis : le premier compte lié. | |
| rafraichir | No | Forcer un appel réseau. Consomme du quota. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it explains the 'etat' field values (observe, ancien, inconnu), instructs not to misinterpret 'inconnu' as zero or failure, and mentions the quota and caching behavior. This gives the agent a clear understanding of what to expect and how to handle edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of three sentences that efficiently convey the core functionality, the response's reliability states, and the quota constraint. No unnecessary verbosity; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides essential context about the response, including the 'etat' and 'age_lisible' fields, and the quota behavior. However, it does not detail the full response structure (e.g., balance amount, currency) or specify behavior for multiple accounts, which could be considered a minor gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant context beyond the schema: it explains the operational impact of 'rafraichir' (consumes quota, forces network call) and clarifies the default behavior. It also relates the 'etat' field to the parameters, enhancing the schema's basic definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns the available balance of each account, with detailed explanation of the 'etat' field. It is distinct from the sibling tools (health, accounts, schedules, transactions, projections) as it specifically targets balances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to set 'rafraichir' to true versus false, based on the quota and need for real-time data. However, it does not explicitly differentiate when to use this tool over the sibling tools, though the purpose inherently implies it for balance queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Les opérations passées d'un compte, les plus récentes d'abord. Sert à vérifier une échéance annoncée ou à retrouver un achat précis. Toute réponse porte etat : "observe" (lu à l'instant), "ancien" (servi du cache, voir age_lisible) ou "inconnu" (rien de fiable — ne jamais présenter cela comme un solde nul ou une panne).
| Name | Required | Description | Default |
|---|---|---|---|
| jours | No | Profondeur en jours (défaut 30). | |
| compte | No | Identifiant du compte. Omis : le premier compte lié. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description thoroughly explains the 'etat' field, including the distinction between 'observe', 'ancien', and 'inconnu', and warns against misinterpreting 'inconnu' as a zero balance or failure. This provides strong transparency about caching and data reliability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, using two sentences to cover purpose, usage, and the important 'etat' semantics. Every sentence adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (two optional parameters) and the lack of an output schema, the description adequately covers the essential behavior, including the meaning of the 'etat' field. It doesn't specify all returned transaction fields, but that is often assumed for a transaction list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes both parameters ('jours' as days with default, 'compte' as identifier with fallback). The description adds no additional parameter-specific meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves past transactions for an account, ordered most recent first. It also provides specific use cases like verifying a due date or finding a purchase, which clarifies its purpose. However, it lacks an explicit verb like 'list' or 'get', so it's not maximally direct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives specific scenarios when to use the tool ('check an announced due date' or 'find a specific purchase'), which serves as guidance. It doesn't explicitly compare to sibling tools, but the context is sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0banque_comptesbanque_echeancesbanque_projectionbanque_santebanque_soldesbanque_transactionsScored across 6 tools
Each tool targets a distinct aspect of banking data: health/status, accounts, balances, recurring operations, transactions, and projections. No two tools overlap in purpose, making selection unambiguous.
All tool names follow the consistent banque_<noun> pattern, clearly indicating the banking domain and the resource each tool addresses. This naming convention is uniform and predictable.
With exactly six tools, the server is well-scoped for its purpose. Each tool covers a necessary function for banking analysis, and the count is within the ideal 3-15 range.
The tool set provides comprehensive coverage of the banking domain: health checks, account listing, balances, recurring payment detection, transaction history, and cash-flow projection. There are no obvious missing capabilities for a read-only banking analytics tool.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Demo banking MCP server: accounts, transactions and payments. OAuth 2.1 with DPoP.
MCP server for Modern Treasury — payment orders, transactions, counterparties and ledgers.
MCP server for Codat — companies, connections, invoices, bills and financial statements.
