openbanking-mcp — 口座を読み取り、事前に警告する
リポジトリ名は
openbanking-mcp、コマンド名はbankread。 これは不注意ではない。リポジトリ名はそれが何であるかを示している — Open Banking の上に載る MCP サーバーだ — なぜなら、それが検索方法だからだ。コマンド名は何をするかを示しており、bankread doctorはopenbanking-mcp doctorよりも打ちやすい。設定パス（~/.config/bankread、キーチェーンbankread-enablebanking）はリポジトリではなくコマンドに従う。
DSP2（AIS認可）による銀行口座の読み取り専用アクセスに加え、Todoist への日次ブリーフ。Python 3.11+、サードパーティ依存ゼロ：HTTP には urllib、MCP サーバーには手書きの JSON-RPC。Mac 上で動作し、クラウドでは動かない。
⚠ データプロバイダーは要選択 — 始める前に読むこと
このリポジトリは GoCardless Bank Account Data（旧 Nordigen）クライアントとともに生まれた。それは明白な無料ルートだった。2026-08-20 に確認済み：このサービスは新規登録を終了し、停止に向かっている。したがって
bankreadlib/gocardless.pyはすでにアカウントを持っている人にのみ役立つ。個人利用のための無料の代替は Enable Banking であり、その Restricted Production ティアは、自分で接続した口座のみについて本物の本番データを提供する — これはまさにここでの用途であり、ライセンス料も不要だ。Enable Banking クライアントは書かれている（
bankreadlib/enablebanking.py）：メールによるセルフサービス登録、RS256 署名付き JWT による認証 — 依存なしで、標準ライブラリで十分だ（bankreadlib/rs256.py）。BoursoBank に実用的なソリューションの一巡と、コードを変えた3つの発見はdocs/fournisseurs.mdにある。誰にも代わりにできないことが一つ残っている：Enable Banking アカウントを作成し、そこに銀行口座を申告し、同意に署名すること。 アプリケーションIDと秘密鍵は個人のものだ — 共有するものは何もなく、そこから始める必要がある。
リポジトリの他のすべてはプロバイダーに依存しない。
BoursoBank はすでに「残高が少なくなっています」を送る。Caisse d'Épargne はすでに「入金がありました」を送る。Amazon は「配送中です」、Leboncoin は「出品者が確認しました」を送る。情報はすでに届いている — ただ遅すぎて、間違った場所に届くだけだ。
遅すぎる：閾値アラートは引き落としの後に発動する。15日の朝、税金は引き落とされ、残高は少なく、アラートはそれを確認するだけだ；
間違った場所：読まれていないものが多い200通のメールの真ん中。
したがって、このリポジトリは不足している情報を探しに行くわけではない。誰もやらない唯一のことをやる：引き算だ。今日の残高から、月末までに落ちるものを引く。銀行も税務署もそれをできない — どちらも相手が見えないからだ。
解決しない問題：ここにあるものは、自分の口座を確認することを代替しない。新しい、見たことのない引き落としは、周期性検出器には見えない。
Related MCP server: pocketledger
接続はプロバイダー（Enable Banking、無料ティア Restricted Production）の DSP2 / AIS 認可を通る。AIS とは口座情報の集約だ。支払い開始は別の認可（PIS）であり、このトークンはそれを持たず、銀行もそれを開かない。漏洩の最悪のシナリオは履歴の読み取りであり、資金の移動ではない。 これがこのリポジトリが存在することを許される唯一の理由だ。
実用的な帰結が3つ：
プロバイダーの認証情報はmacOS キーチェーンに置かれ、ファイルには置かれない — ファイルはバックアップの tar や、うっかりした cat、NAS への rsync に紛れ込む。Enable Banking の場合、これには RSA 秘密鍵も含まれる：bankread secrets --set がそれを読み取り、保管し、ダウンロードした .pem を削除するよう促す；
銀行の同意は期限切れになる — 銀行が与えるものに応じて3〜6ヶ月、そして記録されるのは私たちの要求ではなく銀行の回答だ。誰もあなたの代わりにそれを更新できない：自分の銀行のサイトに戻る必要がある。doctor は J-14 に警告する（J-1 ではない。そこでは週末だけで全てが失効しうる）；
すべては Mac 上で動く。クラウドセッションでもコンテナでもない。
./bankread demo架空の口座、400日分の人工的な履歴、架空の残高 — そしてその上で動く本物の検出と本物の予測。一時ディレクトリの外には何も書かれない。
デモが示すもの、それがすべての要点だ：
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)家賃はまだ下限を上回っている；税金がそれを下回らせる、給料の5日前に。あなたの銀行は25日の朝にそれを言うだろう。そして最後の行が最も重要だ：固定資産税は履歴に2回しか通っていないので、信頼されず、したがってカウントされない — そして予測は、見せかけをする代わりに、自分が楽観的であると自ら宣言する。
3つの方法、要求するコミットメントの順に：
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 # à demeure最初にクローン、習慣ではなく：銀行口座を読むツールは、インストールする前に読まれるべきだ。./bankread はクローンから動作し、何もインストールしない。
# 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édiatこれがこのリポジトリが書かれた銀行なので、一般論ではなく期待すべきことはこれだ。他の銀行は異なる振る舞いをする — そして最終的な判断はこのファイルではなく bankread banks だ：
約90日分の履歴、それ以上ではない。毎月の支払い — 家賃、EDF、税金の月割り — は最初の読み取りで出てくる：3回の通過で十分だ。年次のはレジスタが蓄積するのを待つ（上記参照）。
検証は BoursoBank アプリを通る（DSP2 強認証）。bankread link の流れはサイトを開き、その後電話が鳴る。したがって手元に用意し、この操作を90日ごとにやり直す必要がある。
Wicount 360 の集約に頼らないこと。 BoursoBank はすでに Caisse d'Épargne の口座を集約し、それについてアラートを送るが、DSP2 は照会された銀行が保有する口座へのアクセスを与えるのであって、他から集約したものではない。したがって Caisse d'Épargne の口座は、独自の90日間の同意を持つ、独自の bankread link を必要とする。（最初の接続時に確認すべき：外部口座がフローに現れるなら、なお良い。）
共同口座は銀行の同意画面で選択する。本当に読みたいものだけにチェックを入れる：チェックしたものはローカルレジスタに入り、レジスタは忘れない。
bankread banks bourso は正確な名前を与える — Enable Banking では銀行は技術的IDではなく、その名前と国で指定される — そしてその銀行が与える最大同意期間を与える。最終的な判断はこのファイルではなく、その値だ。
link は自動的にゴールデンウィンドウの取得に進む：完全な履歴は署名後1時間以内にのみ提供され、その後銀行は90日のスライディングに戻る。このステップを中断しないこと — それは次の更新、3〜6ヶ月後まで再実行されない。
| 何が動いているか、何が壊れるか、いつか。ネットワーク呼び出しなし — クォータを消費する診断は、実行する勇気が出ない診断だ。 |
| 残高とその古さ |
| 検出された支払いとその次の通過 |
| 交差：残高から今後の支払いを引いたもの、日ごと |
| 最新の取引 |
| すべてを一度に、スクリプト用に |
| 架空の口座での結果 — 銀行なし、登録なし |
| stdio 上の MCP サーバー、6つの読み取りツール — Claude や他の MCP クライアント用 |
終了コード：0 すべて正常、1 確認すべきものあり、2 ハード失敗 — launchd や呼び出し側スクリプトが判別できるように。
claude mcp add bankread -s user -- "$PWD/bankread" mcpまたはクローンなしで、任意の MCP サーバーが配布されるのと同じように：
{
"mcpServers": {
"bankread": {
"command": "uvx",
"args": ["--from", "git+https://github.com/Beennnn/openbanking-mcp", "bankread", "mcp"]
}
}
}MCP はオープンプロトコルであり、bankreadlib/mcp.py は手書きの JSON-RPC だ：エディタのライブラリも、トークンも、発信呼び出しもない。同じサーバーが他の MCP クライアントでも同じように宣言され、bankread json は MCP でないものに役立つ。すべて — 完全に使わない方法を含めて — は docs/integration.md にある。
口座ごとに1日4回の呼び出し。 ほとんどの銀行は、バックグラウンドで行われる取得を口座ごとに1日4回に制限している。4回。これはかろうじて触れる限界ではなく、デバッグの午前中に到達する限界だ。したがってキャッシュは快適さではなく必須だ：それなしでは、朝のブリーフは2日に1回失敗する。したがって --refresh もあり、それは明示的であり、決してデフォルトではない。
上限は、ユーザーが実際に画面の前にいるときに解除される。これは PSU ヘッダーが銀行に宣言するものだ。bankread はコマンドがターミナルを持つ場合にのみそれを送る：朝7時30分のブリーフはターミナルを持たないので、制限されたままになる。これは銀行への宣言であり、パフォーマンス設定ではない — launchd エージェントから「真」に設定することは嘘になる。
短い履歴は予測を楽観的にするのであって、不完全にはしない。 すべての銀行が13ヶ月を返すわけではない — BoursoBank は約90日を返す。 380日未満では、年次の支払い（固定資産税、保険、使用料）は2回通過するのを見られていないため、検出器にとって存在せず、したがって宣言される軌道は実際より良い。間違えるとお金がかかる唯一の場所なので、upcoming、project、doctor はそれを明確に言う。
そして何よりも、それが ledger.py がキャッシュではなく蓄積する理由です。最初の草案（2026-08-20、朝）はスナップショットを保持していました。各読み取りが前のものを置き換えていました。90日間の銀行では、それは年次の期日を「まだ検出されていない」ではなく生涯検出不能にしました。四半期を超えるものはすべてAPIとキャッシュから同時に消えていました。台帳は各読み取りを永続ファイルに溶かし込みます。1年間のブリーフの後、bankreadは銀行が90日しか表示しないところで365日を知っており、固定資産税は2回目の通過で現れます。bankread doctor はカウントダウンを表示します。
観測されていない緑の行はない。
read.py のすべての応答には etat フィールドがあります：
| 意味 |
| 今読んだばかり、またはまだ真実であるほど十分に最近のもの |
| キャッシュから提供され、年齢が明示されている — 読むべきだが信じるべきではない |
| 何かを主張するほど新しいものがない |
裸の残高は決してありません。solde: null, etat: "inconnu" はゼロ口座ではありません。これは欠落した数字の最悪の読み取り方です。MCPツールの説明は、モデルが呼び出す前にそれを繰り返し、間違えることで学ばないようにします。
予測にも同じ規律があります。2回見た期日は期日ではなく、偶然です。confidence: "faible" とマークされて出力され、予測には入りません。3回の定期的な通過は事実です。
収入についても同様です。支出だけを予測すると常に下落する軌道になり、毎日アラームが出て、1週間後にはアラームがまったく出なくなります。給与と手当は同じ経路で検出され、逆方向に数えられます。test_le_salaire_qui_arrive_avant_evite_la_fausse_alerte がこのケースを守っています。
brief/brief.md は、launchdが brief/run-brief を介して起動し、Claudeが毎朝実行するテキストです。Gmailと銀行を読み取り、その唯一の有用な出力は auto-brief とラベル付けされた少数のTodoistタスクです。
沈黙は成功です。 報告することが何もない朝はゼロタスクを生成します。毎日の要約も「報告事項なし」もありません。タスクを作成するのは5つの理由だけで、~/.config/bankread/brief-vu.json というノートは、同じ遅延パッケージが2週間毎日1つ生成するのを防ぎます。
run-brief は claude --allowedTools に閉じたツールリストを渡します。Gmail書き込みツールは含まれていません。ブリーフはメールを読むだけで、決して返信しません。また、7時30分に画面の前に誰もいないため、承認要求に委ねられるものは何もありません。
呼び出されるモデルは交換可能なドライバー（brief/agents/）であり、ハードコードされた呼び出しではありません。BANKREAD_AGENT=aucun brief/run-brief はAIなしでブリーフを実行し、予測はそれでもジャーナルに落ちます。口座の読み取りにモデルは必要ありませんでした — docs/integration.md を参照してください。
launchd/install.sh はこのエージェントだけをインストールします。名前以上のことをするインストールスクリプトは、結局死んだものを再インストールし、2つのコピーが動いている理由を探して夜を過ごすことになります。
結合は薄く、テスト（test_le_contrat_tient_en_deux_methodes）で検証されています：
プロバイダーに依存するか？ | |
| はい — トークン、クォータ、HTTP、同意フロー |
| どれをロードするかを選択し、契約を |
| はい、部分的に — リンクフロー |
| いいえ、直接インポートはもう1つもありません |
3番目のプロバイダーを接続するには、これら2つのメソッドを公開するモジュールだけで十分です。provider.py の Protocol がそれらを宣言し、provider.charger() が選択を行います：
balances(account_id) -> {"balances": [...]}
transactions(account_id, date_from, date_to) -> {"transactions": {"booked": [...]}}期待される形式はベルリングループのものです。残高には balanceType / balanceAmount、取引には bookingDate と符号付き transactionAmount です。プロバイダーが別のものを話す場合、翻訳はそのクライアントでのみ支払われ、他のどこでもありません — enablebanking._operation() を参照してください。これはEnable Bankingが常に正の値で提供する金額に符号を戻します。
Enable Bankingクライアントを書く際に遭遇した3つの落とし穴、再発見しないためのもの：
金額の符号は金額の隣（credit_debit_indicator）にあり、中にはありません。そのままコピーすると、すべての引き落としが収入として数えられます。
完全な履歴は署名後1時間しか持続しません（上記参照）。
付与された同意の期間は要求されたものより短い場合があります。記録するのは銀行の応答です。そうしないと、doctor は同意が死んでから2ヶ月後に有効と宣言します。
python3 test_bankread.py51テスト、標準ライブラリのみ、ネットワークなし。主にコードが沈黙すべきケースを検証しています。2回の出現は期日にならない、30時間のキャッシュはもはや残高ではない、観測されたことのない残高では予測しない。日付を間違える検出はクラッシュしません — 同じ自信を持って15日ではなく12日に税金を発表します。
~/.config/bankread/state.json（リンクされた口座、トークン、同意日）と ~/.cache/bankread/ — このマシンとこの同意に固有のものです。プロバイダーの資格情報はディスク上のどこにもありません。macOSキーチェーン、サービス bankread-enablebanking（または bankread-gocardless）にあり、RSA秘密鍵も含まれます。
⚠️ ~/.local/share/bankread/ledger/ は別です。これは台帳であり、パージされません。 そこに含まれるものは、銀行が再び提供することはできません。90日を超えると、銀行は忘れてしまいます。キャッシュと一緒に削除すると、3ヶ月のメモリからやり直すことになります。この混乱を難しくするために、キャッシュではなくデータに正確に保管されています。受け入れられた代償：ディスク上に0600の権限で1年間の銀行取引が平文で存在します。
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.
