openbanking-mcp — lire ses comptes, et prévenir AVANT
Le dépôt s'appelle
openbanking-mcp, la commande s'appellebankread. Ce n'est pas une inattention : le nom du dépôt dit ce que c'est — un serveur MCP au-dessus de l'Open Banking — parce que c'est comme ça qu'on le trouve. Le nom de la commande dit ce qu'on en fait, etbankread doctorse tape mieux queopenbanking-mcp doctor. Les chemins de configuration (~/.config/bankread, trousseaubankread-enablebanking) suivent la commande, pas le dépôt.
Lecture seule des comptes bancaires par la DSP2 (agrément AIS), plus un brief quotidien
vers Todoist. Python 3.11+, aucune dépendance tierce : urllib pour l'HTTP, JSON-RPC
écrit à la main pour le serveur MCP. Tourne sur le Mac, pas dans un nuage.
⚠ Le fournisseur de données est à choisir — lire avant de commencer
Ce dépôt est né avec un client GoCardless Bank Account Data (ex-Nordigen), qui était la voie gratuite évidente. Vérification faite le 2026-08-20 : ce service est fermé aux nouvelles inscriptions et en cours d'arrêt.
bankreadlib/gocardless.pyne sert donc qu'à qui avait déjà un compte.Le remplaçant gratuit pour un usage personnel est Enable Banking, dont le palier Restricted Production donne de la vraie donnée de production sur les seuls comptes qu'on relie soi-même — ce qui est exactement l'usage ici, et sans licence à payer. Le client Enable Banking est écrit (
bankreadlib/enablebanking.py) : inscription en libre-service par email, authentification par JWT signé RS256 — sans dépendance, la bibliothèque standard suffit (bankreadlib/rs256.py). Le tour des solutions praticables pour BoursoBank et les trois découvertes qui ont changé le code sont dansdocs/fournisseurs.md.Il reste une chose que personne ne peut faire à ta place : créer le compte Enable Banking, y déclarer tes comptes bancaires, et signer le consentement. L'identifiant d'application et la clé privée sont personnels — il n'y a rien à mutualiser, et c'est par là qu'il faut commencer.
Tout le reste du dépôt est indépendant du fournisseur.
BoursoBank envoie déjà « votre solde est bas ». La Caisse d'Épargne envoie déjà « entrée d'argent ». Amazon envoie « en cours de livraison », Leboncoin « le vendeur a confirmé ». L'information arrive déjà — elle arrive juste trop tard et au mauvais endroit.
trop tard : une alerte de seuil se déclenche APRÈS le prélèvement. Le 15 au matin, les impôts sont passés, le compte est bas, et l'alerte le constate ;
au mauvais endroit : au milieu de deux cents mails, dont la plupart ne sont pas lus.
Ce dossier ne va donc pas chercher une information qui manque. Il fait la seule chose que personne ne fait : la soustraction. Le solde d'aujourd'hui moins ce qui va tomber d'ici la fin du mois. Ni la banque ni les impôts ne peuvent la faire — aucun des deux ne voit l'autre.
Ce qu'il ne règle pas : rien ici ne remplace le fait de regarder ses comptes. Un prélèvement nouveau, jamais vu, est invisible pour un détecteur de récurrences.
Related MCP server: pocketledger
Le lien passe par l'agrément DSP2 / AIS du fournisseur (Enable Banking, palier gratuit Restricted Production). AIS, c'est l'agrégation d'informations sur les comptes. L'initiation de paiement est un agrément séparé (PIS), que ce jeton n'a pas et que la banque ne lui ouvrira pas. Le pire scénario d'une fuite est la lecture d'un historique, jamais un mouvement d'argent. C'est la seule raison pour laquelle ce dossier a le droit d'exister.
Trois conséquences pratiques :
les identifiants du fournisseur vivent dans le trousseau macOS, pas dans un
fichier — un fichier finit dans un tar de sauvegarde, un cat malheureux, un rsync
vers un NAS. Pour Enable Banking, ça inclut la clé privée RSA : bankread secrets --set la lit, la range, et rappelle de supprimer le .pem téléchargé ;
le consentement bancaire expire — trois à six mois selon ce que la banque accorde,
et c'est sa réponse qui est enregistrée, pas notre demande. Rien ne peut le renouveler
à ta place : il faut retourner sur le site de sa banque. doctor prévient à J-14 (pas
à J-1, où un week-end suffirait à tout périmer) ;
tout ça tourne sur le Mac. Pas dans une session cloud, pas dans un conteneur.
./bankread demoUn compte inventé, 400 jours d'historique fabriqué, un solde imaginaire — et la vraie détection et la vraie projection qui tournent dessus. Rien n'est écrit hors d'un dossier temporaire.
Ce que la démonstration montre, et qui est tout le propos :
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)Le loyer laisse encore au-dessus du plancher ; ce sont les impôts qui font passer dessous, cinq jours avant le salaire. Ta banque le dira le 25 au matin. Et la dernière ligne est la plus importante : la taxe foncière n'est passée que deux fois dans l'historique, donc elle n'est pas crue, donc elle ne compte pas — et la projection annonce elle-même qu'elle est optimiste plutôt que de faire semblant.
Trois façons, dans l'ordre de l'engagement qu'elles demandent :
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 # à demeureLe clone en premier, et pas par habitude : un outil qui lit des comptes bancaires se lit
avant de s'installer. ./bankread marche depuis le clone, sans rien installer du tout.
# 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édiatC'est la banque contre laquelle ce dépôt a été écrit, donc voici ce à quoi s'attendre
plutôt qu'une généralité. Une autre banque se comportera autrement — et c'est
bankread banks qui fait foi, pas ce fichier :
~90 jours d'historique, pas plus. Les échéances MENSUELLES — loyer, EDF, mensualisation des impôts — sortent dès la première lecture : trois passages suffisent. Les annuelles attendent que le registre ait accumulé (voir plus haut).
La validation passe par l'app BoursoBank (authentification forte DSP2). Le
parcours bankread link ouvre le site, puis le téléphone sonne. Il faut donc l'avoir
sous la main, et refaire ce geste tous les 90 jours.
Ne pas compter sur l'agrégation Wicount 360. BoursoBank agrège déjà le compte
Caisse d'Épargne et envoie des alertes dessus, mais la DSP2 donne accès aux comptes
tenus par la banque interrogée, pas à ce qu'elle agrège d'ailleurs. Le compte Caisse
d'Épargne demande donc son propre bankread link, avec son propre consentement de
90 jours. (À confirmer lors du premier branchement : si les comptes externes
apparaissent dans le parcours, tant mieux.)
Les comptes joints se choisissent dans l'écran de consentement de la banque. Ne cocher que ce qu'on veut vraiment lire : ce qui est coché part dans le registre local, et le registre ne s'oublie pas.
bankread banks bourso donne le nom exact — chez Enable Banking une banque se désigne
par son NOM et son pays, pas par un identifiant technique — et la durée de consentement
maximale que cette banque accorde. C'est cette valeur qui fait foi, pas ce fichier.
link enchaîne tout seul sur le rapatriement de la fenêtre d'or : l'historique
complet n'est servi que dans l'heure qui suit la signature, ensuite la banque retombe à
90 jours glissants. Ne pas interrompre cette étape — elle ne se rejoue qu'au prochain
renouvellement, dans trois à six mois.
| ce qui marche, ce qui va casser, quand. Aucun appel réseau — un diagnostic qui consomme du quota est un diagnostic qu'on n'ose pas lancer. |
| les soldes, avec leur âge |
| les échéances détectées et leur prochain passage |
| le croisement : solde moins les échéances à venir, jour par jour |
| les dernières opérations |
| tout d'un coup, pour un script |
| ce que ça donne, sur un compte FICTIF — sans banque, sans inscription |
| serveur MCP sur stdio, six outils de lecture — pour Claude ou tout autre client MCP |
Codes de sortie : 0 tout va bien, 1 il y a à regarder, 2 échec dur — pour que launchd et les scripts appelants s'y retrouvent.
claude mcp add bankread -s user -- "$PWD/bankread" mcpOu sans clone du tout, comme se distribue n'importe quel serveur MCP :
{
"mcpServers": {
"bankread": {
"command": "uvx",
"args": ["--from", "git+https://github.com/Beennnn/openbanking-mcp", "bankread", "mcp"]
}
}
}MCP est un protocole ouvert et bankreadlib/mcp.py est du JSON-RPC écrit à la main :
aucune bibliothèque d'éditeur, aucun jeton, aucun appel sortant. Le même serveur se
déclare de la même façon dans les autres clients MCP, et bankread json sert ce qui n'en
est pas. Le tout — y compris comment s'en passer complètement — est dans
docs/integration.md.
Quatre appels par jour et par compte. La plupart des banques plafonnent à quatre
appels par compte et par jour le rapatriement fait en arrière-plan. Quatre. Ce n'est
pas une limite qu'on frôle, c'est une limite qu'on atteint en une matinée de mise au
point. D'où un cache qui n'est pas un confort : sans lui, le brief du matin échoue un
jour sur deux. D'où aussi --refresh, qui est explicite et jamais le défaut.
Le plafond tombe quand un utilisateur est réellement devant l'écran, ce qu'un en-tête PSU déclare à la banque. bankread ne l'envoie que si la commande a un terminal : le brief de 7 h 30 n'en a pas, donc il reste plafonné. C'est une déclaration faite à une banque, pas un réglage de performance — la mettre à « vrai » depuis un agent launchd serait un mensonge.
Un historique court rend une projection OPTIMISTE, pas incomplète. Toutes les banques
ne rendent pas treize mois — BoursoBank en rend environ 90 jours. En dessous de
380 jours, une échéance annuelle (taxe foncière, assurance, redevance) n'a pas pu être
vue passer deux fois, donc elle n'existe pas pour le détecteur, donc la trajectoire
annoncée est meilleure que la vraie. C'est le seul endroit où se tromper coûte de
l'argent, alors upcoming, project et doctor le disent en toutes lettres.
Et surtout, c'est pour ça que ledger.py accumule au lieu de mettre en cache. Le
premier jet (2026-08-20, matin) gardait un instantané : chaque lecture remplaçait la
précédente. Avec une banque à 90 jours, ça rendait une échéance annuelle non pas
« pas encore détectée » mais indétectable à vie — tout ce qui dépassait le trimestre
disparaissait de l'API et du cache en même temps. Le registre fond chaque lecture dans
un fichier durable ; au bout d'un an de briefs, bankread connaît 365 jours là où la
banque n'en montre que 90, et la taxe foncière apparaît à son deuxième passage.
bankread doctor affiche le compte à rebours.
Aucune ligne verte qui n'ait été observée.
Toute réponse de read.py porte un champ etat :
| ce que ça veut dire |
| lu à l'instant, ou assez récemment pour être encore vrai |
| servi du cache, avec son âge en clair — à lire, pas à croire |
| on n'a rien d'assez frais pour prétendre quoi que ce soit |
Jamais un solde nu. Un solde: null, etat: "inconnu" n'est pas un compte à zéro, et
c'est la pire lecture possible d'un chiffre manquant — les descriptions des outils MCP le
répètent au modèle avant qu'il appelle, pour qu'il ne l'apprenne pas en se trompant.
Même discipline sur les prédictions : une échéance vue deux fois n'est pas une échéance,
c'est une coïncidence. Elle sort marquée confidence: "faible" et n'entre pas dans la
projection. Trois passages réguliers, c'est un fait.
Et sur les rentrées : projeter les seules sorties donne une trajectoire qui plonge
toujours, donc une alarme tous les jours, donc plus d'alarme du tout au bout d'une
semaine. Le salaire et les allocations sont détectés par le même chemin et comptés dans
l'autre sens. test_le_salaire_qui_arrive_avant_evite_la_fausse_alerte garde ce cas.
brief/brief.md est le texte que Claude exécute chaque matin, lancé par launchd via
brief/run-brief. Il lit Gmail et la banque, et sa seule sortie utile est un petit
nombre de tâches Todoist étiquetées auto-brief.
Le silence est une réussite. Un matin sans rien à signaler produit zéro tâche — pas
de résumé quotidien, pas de « rien à signaler ». Cinq motifs seulement créent une tâche,
et le carnet ~/.config/bankread/brief-vu.json empêche qu'un même colis en retard en
génère une par jour pendant deux semaines.
run-brief passe une liste FERMÉE d'outils à claude --allowedTools. Aucun outil
d'écriture Gmail n'y figure : le brief lit le courrier, il n'y répond jamais. Et rien
n'est laissé à une demande d'autorisation, puisque personne n'est devant l'écran pour y
répondre à 7 h 30.
Le modèle appelé est un pilote remplaçable (brief/agents/), pas un appel en dur :
BANKREAD_AGENT=aucun brief/run-brief fait tourner le brief sans aucune IA, et la
projection tombe quand même dans le journal. La lecture des comptes n'a jamais eu besoin
d'un modèle — voir docs/integration.md.
launchd/install.sh n'installe que cet agent. Un script d'installation qui en fait
plus que son nom finit par réinstaller quelque chose de mort, et on passe la soirée à
chercher pourquoi deux exemplaires tournent.
Le couplage est mince, et c'est vérifié par un test (test_le_contrat_tient_en_deux_methodes) :
dépend du fournisseur ? | |
| oui — jetons, quotas, HTTP, parcours de consentement |
| il choisit lequel charger, et écrit le contrat en |
| oui, partiellement — le parcours de liaison |
| non, et plus une seule importation directe |
Pour brancher un troisième fournisseur, il suffit d'un module qui expose ces deux
méthodes — le Protocol de provider.py les déclare, et provider.charger() en fait le
choix :
balances(account_id) -> {"balances": [...]}
transactions(account_id, date_from, date_to) -> {"transactions": {"booked": [...]}}Le format attendu est celui du Groupe de Berlin : balanceType / balanceAmount pour
les soldes, bookingDate et transactionAmount signé pour les opérations. Si le
fournisseur parle autre chose, la traduction se paie dans son client et nulle part
ailleurs — voir enablebanking._operation(), qui rend leur signe à des montants
qu'Enable Banking livre toujours positifs.
Trois pièges rencontrés en écrivant le client Enable Banking, à ne pas redécouvrir :
le signe des montants est porté à côté du montant (credit_debit_indicator), pas
dedans. Le recopier tel quel ferait compter chaque prélèvement comme une rentrée ;
l'historique complet ne dure qu'une heure après la signature (voir plus haut) ;
la durée du consentement accordée peut être plus courte que celle demandée : c'est
la réponse de la banque qu'on enregistre, sinon doctor annonce un consentement valide
deux mois après sa mort.
python3 test_bankread.py51 tests, stdlib seule, aucun réseau. Ils vérifient surtout les cas où le code doit se taire : deux occurrences ne font pas une échéance, un cache de trente heures n'est plus un solde, on ne projette pas sur un solde jamais observé. Une détection qui se trompe de date ne plante pas — elle annonce les impôts le 12 au lieu du 15, avec le même aplomb.
~/.config/bankread/state.json (comptes liés, jetons, dates de consentement) et
~/.cache/bankread/ — spécifiques à cette machine et à ce consentement. Les identifiants
du fournisseur ne sont nulle part sur le disque : ils sont dans le trousseau macOS,
service bankread-enablebanking (ou bankread-gocardless), clé privée RSA comprise.
⚠️ ~/.local/share/bankread/ledger/ est à part : c'est le registre, et il ne se purge
pas. Ce qu'il contient, la banque ne peut plus le redonner — au-delà de 90 jours, elle
a oublié. Le supprimer avec le cache, c'est repartir à trois mois de mémoire. Il est
rangé dans les données et pas dans le cache exactement pour rendre cette confusion
difficile. Contrepartie assumée : c'est un an d'opérations bancaires en clair sur le
disque, en 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.
