openbanking-mcp — leer sus cuentas y avisar ANTES
El repositorio se llama
openbanking-mcp, el comando se llamabankread. No es un despiste: el nombre del repositorio dice lo que es — un servidor MCP sobre Open Banking — porque así es como se encuentra. El nombre del comando dice lo que se hace con él, ybankread doctorsuena mejor queopenbanking-mcp doctor. Las rutas de configuración (~/.config/bankread, llaverobankread-enablebanking) siguen al comando, no al repositorio.
Lectura de las cuentas bancarias mediante DSP2 (autorización AIS), más un resumen diario
hacia Todoist. Python 3.11+, cero dependencias externas: urllib para el HTTP, JSON-RPC
escrito a mano para el servidor MCP. Se ejecuta en el Mac, no en una nube.
⚠ El proveedor de datos hay que elegirlo — leer antes de empezar
Este repositorio nació con un cliente GoCardless Bank Account Data (ex-Nordigen), que era la vía gratuita evidente. Comprobado el 2026-08-20: este servicio está cerrado a nuevas suscripciones y en proceso de retirada.
bankreadlib/gocardless.pyya solo sirve a quien ya tenía una cuenta.El sustituto gratuito para un uso personal es Enable Banking, cuyo nivel Restricted Production da datos reales de producción sobre las únicas cuentas que uno mismo conecta — que es exactamente el uso que se le da aquí, y sin licencia que pagar. El cliente Enable Banking ya está escrito (
bankreadlib/enablebanking.py): alta en autoservicio por correo electrónico, autenticación mediante JWT firmado con RS256 — sin dependencias, con la biblioteca estándar basta (bankreadlib/rs256.py). El recorrido por las soluciones practicables para BoursoBank y los tres hallazgos que cambiaron el código están endocs/fournisseurs.md.Queda una cosa que nadie puede hacer por ti: crear la cuenta de Enable Banking, declarar en ella tus cuentas bancarias y firmar el consentimiento. El identificador de la aplicación y la clave privada son elementales personales — no hay nada que compartir, y es por ahí por donde hay que empezar.
Todo el resto del repositorio es independiente del proveedor.
BoursoBank ya envía «su saldo es bajo». La Caisse d'Épargne ya envía «entrada de dinero». Amazon envía «en reparto», Leboncoin «el vendedor ha confirmado». La información ya llega — solo que llega demasiado tarde y al lugar equivocado.
demasiado tarde: una alerta de umbral se dispara DESPUÉS del cargo. El día 15 por la mañana, los impuestos han pasado, la cuenta está baja, y la alerta lo constata;
en mal lugar: entre doscientos correos, la mayoría de los cuales no se envían.
Este proyecto no busca, por tanto, una información que falte. Hace la única cosa que naddie más hace: la resta. El saldo de hoy menos lo que va a caer antes de que hasta final de mes. Ni el banco ni los impuestos pueden hacerla — ninguno de los dos ve al otro.
Lo que no resuelve: nada aquí sustituye al hecho de mirar las cuentas. Un recargo nuevo, nunca visto es invisible para un detector de recurrencias.
Related MCP server: pocketledger
El vínculo pasa por la autorización DSP2 / AIS del proveedor (Enable Banking, nivel gratuito Restricted Production). Lol, la ISS es la colocación de la información sobre las cuentas. La iniciación de pagos es una autorización aparte (PIS), que ese token tiene no tiene nada para que el banco obtenga. El peor escenario de una filtración es la lectura de un historial, nunca de un movimiento de dinero. Esa es la única razón por la que este proyecto tiene derecho de existir.
Dos consecuencias prácticas:
las identificaciones del proveedor viven en el llavero de macOS, no en un
archivo — unarchivo acaba en un tar de copia, un cat infeliz, un madeja hacia un
NAS. Para Enable Banking, esto incluye la clave privada RSA: bankread secrets --setfront la lee,
la guarda y recuerda que hay que borrar el .pem descargado;
el consentimiento ha de volver a firmarlo — tres a seis meses según lo que el banco
conceda, y es su respuesta la que queda registrada, no nuestra petición.
Nada puede renovarlo en tu place: hay que volbar a la web de tu banco. doctor
lo avisa el día D-14 (no el D-1, que un solo fin de semana bastaría para remarar);
todo esto se ejecuta en el Mac. No en una sesión de cloud, no en un contenedor.
./bankread demoUna cuenta inventada, 400 días de historial fabricado, un saldo imaginario — y, entre tanto, la detección y la proyección reales que trabajan con él. Nada se escribe fuera de la carpeta temporal.
Lo que el demonio muestra, y que es todo el trabajo:
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)El alquiler sigue debajo del salario; los impuestos lo hacen caer, cinco días antes de que se reciba la nómina. Tu banco te lo dirá un día 25 por la mañana. Yuna última línea es la más importante: la piscina de la vivienda (el el IBI) no ha pasado aún de dos veces en el historial, por lo tanto lo que aparece no se puede verificar no cuenta — y la proyección proyección ahora mismo dice que es optimista en lugar de hacer como que no es nada para no quedar.
Tres formas, según el grado de compromiso que piden:
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 # à demeureEl intermedio, y no probe: una herramienta que lee cuentas bancarias se lee
antes de leerse. ./bankread funciona desde el clon, sin instalar nada.
# 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édiatEs el banco contra el que se ha escrito este repositorio, así que esto es lo que cabe esperar
y no una generalidad. Otro banco se comportará de otro modo — and the one with the
bankread banks la que manda, no this archivo:
~90 días de historial, no más. Las dels mensuales — alquiler, luz, domiciliación de impuestos — salen para leer la primera lectura: tarifa de tres. La anualidad de espera a que el registro vaya acumulando (ver rand).
La validación pasa por la app BoursoBank (autenticación fuerte DSP2). El
camino bankread link abre el sitio, y el teléfono suena. Así que hay que
tenerlo a mano, y volver a hacer este paso cada 90 días.
No confiar en el agregador Wicount 660. BoursoBank ya agrega el poder de la Caisse
d'Épargne y envía alertas sobre él, pero la DSP2 da acceso solo a las cuentas
atadas por el banco consultado, no que agrega. El de la caja
de ahorros necesita, por tanto, su propio bankread, form con su propio consent
de 90 días. (A barredor of this connection: si las cuentas externas no
aparecen en el tour, mejor.)
Las cuentas conjuntas se eligen en la pantalla de consent del banco. No marcar más que lo que sigue de verdad: todo coin se va al registro de toursi, y el registro de no se olvida.
bankread banks bourso da el nombre exacto — en Enable Banking el banco se identifica
por la SULetra de alifuNTE y el país, no por un parámetro técnico — y la duración
máxima de consentimiento que concede ese banco. Es ese valor el que tuvo la validez, no este
archivo.
El link va seguido del cierre de la cuenta de oro: el históral de
completo no se sirve solamente dentro de la hora siguiente a la firma; luego el banco
vuelve a 90 días consecutivos. No interrumpir esto paso.
a la renovación siguiente, de tres a seis meses.
| lo que funciona, lo que va a fallar, y cuándo. Ninguna llamada — un diagnostico que consume cuota es un diagnóstico que nadie quiere ya. |
| los saltos, con su antigüedad |
| los vencimientos detectados y su próxima vez por |
| el cruce: saldo menos los vencimientos que vienen, día a día |
| las últimas operaciones |
| todo de una vez, para un script |
| lo que se obtiene, sobre una cuenta FICTICIA — sin banco, sin plaza |
| servidor MCP sobre Stdio, seis herramientas de lectura — para Claude o cualquier otro cliente |
Códigos de salida: 0 todo bien, 1 hay algo que mirar, 2 fallo grave, para que launchd y los scripts de destino se principien.
claude mcp add bankread -s user -- "$PWD/bankread" mcpO sin el clon del todo, como se distribuye cualquier servidor MCP:
{
"mcpServers": {
"bankread": {
"command": "uvx",
"args": ["--from", "git+https://github.com/Beennnn/openbanking-mcp", "bankread", "mcp"]
}
}
}MCP es un protocol abierto y bankreadlib/m.py es JSON-RPC escrito a mano:
de despliegue, ningún token, ninguna quedada. El mismo servidor se declara
de la misma manera en las demás restantes clotes MCP, y bankread json sirve para
eso que no se por donde. Todo el conjunto (incluido cómo continuar sin él por completo) en
docs/integration.md.
Cuatro llamadas por día y cuenta. La mayoría de las entidades limitan a
cuatro llamadas por día y por cuenta el proceso en background. Cuatro. No
es unlíquido que se acerque, es un límite que se alcanza en una mañana de
de= deses. De ahí el caché que no es comfort: sin él llegarás el reco del
mañana, a una mañana y una mañana. A y, --refresh, que es un apuesta.
... **
El límite se cae cuando un usuario está realmente frente a una pantalla, como un encabezado PSUWO error ante el banco. bankread solo lo envía si la orden tiene un terminal: el beginning de las 7h30 no lo tiene, así que mantiene el límite. Es la marca de un banco, no un lugar de rendimiento.
Un histórico corto hace una proyección OPTIMISTA, no incompleta. No todas
las asiáticas dan trece meses — BoursoBank da unos ~90 días.200
días, bi
una que parece una falta (impuesto de bienes, seguro, tasas) no ha llegado
a verdos veces, así que no existe para el detector, así que la trayectoria
que se anuncia es mejor que la real. Es que es el único lugar en el que
mendo,
equivocarse cuesta dinero, and upcoming, project y
doctor lo dicen con todas las letras.
Y sobre todo, es por eso que ledger.py acumula en lugar de poner en caché. El
primer borrador (2026-08-20, por la mañana) guardaba una instantánea: cada lectura
reemplazaba a la anterior. Con un banco a 90 días, eso hacía que un vencimiento anual no
fuera «aún no detectado» sino indetectable de por vida — todo lo que superaba el
trimestre desaparecía de la API y de la caché al mismo tiempo. El registro funde cada
lectura en un archivo duradero; al cabo de un año de informes, bankread conoce 365 días
allí donde el banco solo muestra 90, y el impuesto predial aparece en su segundo paso.
bankread doctor muestra la cuenta atrás.
Ninguna línea verde que no haya sido observada.
Toda respuesta de read.py lleva un campo etat:
| lo que significa |
| leído al instante, o hace bastante poco como para seguir siendo verdadero |
| servido desde la caché, con su edad en claro — para leer, no para creer |
| no tenemos nada lo bastante fresco como para afirmar nada |
Nunca un saldo desnudo. Un solde: null, etat: "inconnu" no es una cuenta a cero, y
es la peor lectura posible de una cifra que falta — las descripciones de las herramientas MCP lo
repiten al modelo antes de que llame, para que no lo aprenda equivocándose.
Misma disciplina con las predicciones: un vencimiento visto dos veces no es un vencimiento,
es una coincidencia. Sale marcado confidence: "faible" y no entra en la
proyección. Tres pasos regulares, eso es un hecho.
Y con los ingresos: proyectar solo las salidas da una trayectoria que se hunde
siempre, por lo tanto una alarma todos los días, y por lo tanto más alarma en absoluto al cabo de una
semana. El salario y las asignaciones se detectan por el mismo camino y se cuentan en
el otro sentido. test_le_salaire_qui_arrive_avant_evite_la_fausse_alerte conserva ese caso.
brief/brief.md es el texto que Claude ejecuta cada mañana, lanzado por launchd mediante
brief/run-brief. Lee Gmail y el banco, y su única salida útil es un pequeño
número de tareas de Todoist etiquetadas auto-brief.
El silencio es un éxito. Una mañana sin nada que señalar produce cero tareas — no
hay resumen diario, no hay «nada que señalar». Solo cinco motivos crean una tarea,
y el cuaderno ~/.config/bankread/brief-vu.json impide que un mismo paquete retrasado
genere una por día durante dos semanas.
run-brief pasa una lista CERRADA de herramientas a claude --allowedTools. Ninguna herramienta
de escritura de Gmail figura en ella: el informe lee el correo, nunca responde. Y nada
se deja a una solicitud de autorización, ya que nadie está delante de la pantalla para
responder a las 7:30.
El modelo llamado es un piloto reemplazable (brief/agents/), no una llamada fija:
BANKREAD_AGENT=aucun brief/run-brief hace funcionar el informe sin ninguna IA, y la
proyección cae igualmente en el diario. La lectura de las cuentas nunca ha necesitado
un modelo — ver docs/integration.md.
launchd/install.sh solo instala a ese agente. Un script de instalación que hace más
de lo que su nombre dice termina reinstalando algo muerto, y uno se pasa la tarde
buscando por qué dos ejemplares están en marcha.
El acoplamiento es fino, y está verificado por una prueba (test_le_contrat_tient_en_deux_methodes):
¿depende del proveedor? | |
| sí — tokens, cuotas, HTTP, recorrido de consentimiento |
| él elige cuál cargar, y escribe el contrato en |
| sí, parcialmente — el recorrido de vinculación |
| no, y ni una sola importación directa más |
Para conectar un tercer proveedor, basta con un módulo que exponga esos dos
métodos — el Protocol de provider.py los declara, y provider.charger() hace la
elección:
balances(account_id) -> {"balances": [...]}
transactions(account_id, date_from, date_to) -> {"transactions": {"booked": [...]}}El formato esperado es el del Grupo de Berlín: balanceType / balanceAmount para
los saldos, bookingDate y transactionAmount firmado para las operaciones. Si el
proveedor habla otra cosa, la traducción se paga en su cliente y en ningún otro
lugar — ver enablebanking._operation(), que devuelve su signo a unos importes
que Enable Banking entrega siempre positivos.
Tres trampas encontradas al escribir el cliente de Enable Banking, para no redescubrirlas:
el signo de los importes se lleva al lado del importe (credit_debit_indicator), no
dentro. Copiarlo tal cual haría contar cada domiciliación como un ingreso;
el historial completo solo dura una hora después de la firma (ver más arriba);
la duración del consentimiento otorgado puede ser más corta que la solicitada: es
la respuesta del banco lo que se registra, si no doctor anuncia un consentimiento válido
dos meses después de su muerte.
python3 test_bankread.py51 pruebas, solo stdlib, sin red. Verifican sobre todo los casos en los que el código debe callarse: dos ocurrencias no hacen un vencimiento, una caché de treinta horas ya no es un saldo, no se proyecta sobre un saldo nunca observado. Una detección que se equivoca de fecha no se cae — anuncia los impuestos el día 12 en lugar del 15, con la misma seguridad.
~/.config/bankread/state.json (cuentas vinculadas, tokens, fechas de consentimiento) y
~/.cache/bankread/ — específicos de esta máquina y de este consentimiento. Las credenciales
del proveedor no están en ningún lugar del disco: están en el llavero de macOS,
servicio bankread-enablebanking (o bankread-gocardless), clave privada RSA incluida.
⚠️ ~/.local/share/bankread/ledger/ es aparte: es el registro, y no se purga.
Lo que contiene, el banco ya no puede volver a darlo — más allá de 90 días,
lo ha olvidado. Suprimirlo junto con la caché es volver a empezar con tres meses de memoria. Está
guardado en los datos y no en la caché precisamente para hacer difícil esa confusión.
Contrapartida asumida: es un año de operaciones bancarias en claro en el
disco, 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.
