Which integrations are available for this server?

Allows querying accounts, balances, and transactions from CaixaBank via TrueLayer PSD2 API, and generates analytics such as spending by category, subscriptions, unusual charges, and monthly summaries.

How do I use openbanking-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@openbanking-mcp show my last 10 transactions" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

openbanking-mcp

by guille-near

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

openbanking-mcp

Servidor MCP de finanzas personales de solo lectura sobre Open Banking (PSD2), vía Enable Banking. Consulta cuentas, saldos y movimientos de tu banco y genera analítica: gasto por categoría, suscripciones, cargos inusuales y resúmenes mensuales — desde Claude Desktop, Cursor o ChatGPT.

Solo lectura. No inicia pagos ni transferencias: solo se piden permisos de datos (cuentas, saldos y movimientos).

Funciona con casi toda la banca europea (CaixaBank incluido). El banco se elige con ENABLEBANKING_ASPSP_NAME en tu .env.

Aviso

Proyecto independiente, no afiliado ni respaldado por Enable Banking ni por ningún banco. Manejas tus propios datos bancarios bajo tu responsabilidad: cada quien autohospeda con sus credenciales y los datos nunca salen de tu máquina (SQLite local; tokens y clave privada cifrados/protegidos en data/, que está en .gitignore). Software entregado "tal cual", sin garantías (ver LICENSE). Lee las notas PSD2.

Related MCP server: C6 Bank MCP

Arquitectura

Tu banco (PSD2)
   -> Enable Banking (AIS)          [interfaz BankDataProvider]
   -> Capa de sincronización        (pull idempotente e incremental)
   -> SQLite (SQLAlchemy)
   -> Capa de analítica             (funciones puras)
   -> Servidor MCP (solo lectura)
   -> Cliente MCP: Claude Desktop / Cursor / ChatGPT

El servidor MCP lee de SQLite, nunca llama al banco en caliente. La sincronización es un proceso aparte (finmcp sync, manual o por cron).

¿Por qué Enable Banking? Es el agregador AIS self-serve y gratis para uso personal que cubre la banca europea. (GoCardless/Nordigen cerró nuevos registros y la Data API de TrueLayer ya no se concede self-serve.) El código mantiene una interfaz BankDataProvider, así que añadir otro proveedor es sencillo.

Paso a paso

1. Instala el proyecto

git clone https://github.com/guille-near/openbanking-mcp.git && cd openbanking-mcp
python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"

2. Registra tu app en Enable Banking

Entra en enablebanking.com → Control Panel y regístrate.
Crea una aplicación:
- Generación de clave: "Generate in the browser… export private key".
- Allowed redirect URLs: https://localhost:3000/callback (exige HTTPS).
- Rellena nombre, email y (si los pide) URLs de privacidad/términos.
Al registrar, descarga la clave privada (.pem) — solo se muestra una vez — y copia el Application ID (es el nombre del fichero .pem).
Restricted Production: en la app, pulsa Link accounts y vincula (lista blanca) las cuentas de tu banco que quieras leer. En modo Restricted solo se pueden acceder esas cuentas (no requiere due diligence; perfecto para uso personal).

3. Configura el `.env`

cp .env.example .env

Guarda la clave privada en data/enablebanking_private.pem y edita el .env:

FINMCP_PROVIDER=enablebanking
ENABLEBANKING_APP_ID=<tu Application ID>
ENABLEBANKING_COUNTRY=ES
# ENABLEBANKING_KEY_PATH=/ruta/a/clave.pem   # solo si NO usas data/enablebanking_private.pem

4. Elige tu banco

finmcp institutions            # lista las entidades (p.ej. "CaixaBank · ES")

Fija el nombre exacto en el .env:

ENABLEBANKING_ASPSP_NAME=CaixaBank

5. Autoriza y sincroniza

finmcp auth        # abre tu banco para el SCA
finmcp sync        # baja cuentas/saldos/movimientos a SQLite
finmcp accounts    # comprobación

En finmcp auth, tras el SCA el navegador irá a https://localhost:3000/callback y mostrará un error de conexión: es normal. Copia el valor de code de la barra de direcciones (o pega la URL entera) cuando el CLI lo pida. El código nunca sale de tu máquina.

El consentimiento dura ~90 días (límite PSD2); pasado ese plazo, repite finmcp auth.

Comandos

Comando	Descripción
`finmcp auth`	Autoriza con tu banco y guarda la sesión cifrada
`finmcp institutions`	Lista las entidades disponibles (para fijar `ENABLEBANKING_ASPSP_NAME`)
`finmcp sync`	Trae cuentas/saldos/movimientos a SQLite
`finmcp accounts`	Lista las cuentas locales
`finmcp import-csv`	Importa movimientos desde un CSV (histórico anterior a 90 días)
`finmcp categorize`	Reaplica tus reglas de categorización
`finmcp rules add/list`	Gestiona reglas de categorización
`finmcp serve`	Arranca el servidor MCP (stdio; `--http` para remoto)

Herramientas MCP (solo lectura)

list_accounts · get_balances · get_transactions · search_transactions · spend_by_category_tool · list_subscriptions · unusual_charges · monthly_summary_tool · sync_status

Cargos inusuales usa mediana + MAD (robusto): un único pico no contamina su propia línea base, así que se detecta de verdad.

Conectar a Claude Desktop

En claude_desktop_config.json (usa la ruta absoluta a tu clon del repo):

{
  "mcpServers": {
    "openbanking": {
      "command": "/RUTA/ABSOLUTA/A/openbanking-mcp/.venv/bin/finmcp",
      "args": ["serve"]
    }
  }
}

El servidor lee de SQLite; recuerda correr finmcp sync (manual o por cron) para mantener los datos al día.

Conectar a ChatGPT

ChatGPT solo se conecta a servidores MCP remotos por HTTP(S). Hay que exponer el servidor por una URL pública y añadirlo como connector en Modo Desarrollador.

⚠️ Datos bancarios por una URL pública. Usa SIEMPRE bearer token y HTTPS. Para uso solo-local, Claude Desktop (stdio) es más seguro.

export FINMCP_HTTP_TOKEN="<token-largo-aleatorio>"
finmcp serve --http --port 8000        # expone POST /mcp (401 sin el token)
ngrok http 8000                         # túnel HTTPS -> https://xxxx.ngrok.app

En ChatGPT → Connectors → Add custom connector: URL https://xxxx.ngrok.app/mcp, cabecera Authorization: Bearer <FINMCP_HTTP_TOKEN>.

Categorías personalizadas

Enable Banking no envía categoría en los movimientos, así que las defines tú con reglas:

finmcp rules add "mercadona" "Supermercado"
finmcp rules add "vodafone" "Telefonía" --field merchant
finmcp rules list
finmcp categorize            # reaplica todas las reglas

Las reglas se reaplican automáticamente al final de cada finmcp sync. my_category (manual/regla) tiene prioridad sobre cualquier categoría del proveedor.

Importar histórico antiguo (CSV)

Las APIs PSD2 solo dan ~90 días de histórico. Para movimientos más antiguos, exporta tus movimientos desde la web de tu banco (Excel .xlsx o CSV/TXT) e impórtalos:

finmcp import-csv movimientos.xlsx --iban ES58...   # o un .csv / .txt

Acepta Excel (.xlsx y .xls) y texto (CSV/TXT); detecta el delimitador, las cabeceras y el formato español de fecha/importe. Soporta importe en una columna con signo o en columnas Ingreso/Gasto separadas (formato CaixaBank), y si el fichero trae varias cuentas (columna Número de cuenta) mapea cada movimiento a su cuenta. Deduplica por (cuenta, día, importe, tipo), así que es seguro reimportar o solapar con lo que ya bajó la API. Las reglas de categorización se aplican solas.

Sincronización programada (macOS / launchd)

# Sustituye __PROJECT_DIR__ por la ruta absoluta de tu clon
sed -i '' "s|__PROJECT_DIR__|$PWD|g" deploy/com.openbanking-mcp.sync.plist

# Copia el LaunchAgent y actívalo (sync cada 6 h)
cp deploy/com.openbanking-mcp.sync.plist ~/Library/LaunchAgents/
launchctl load ~/Library/LaunchAgents/com.openbanking-mcp.sync.plist

# Logs en data/sync.log · para parar:
launchctl unload ~/Library/LaunchAgents/com.openbanking-mcp.sync.plist

Notas PSD2

El consentimiento PSD2 caduca: hay que re-autorizar con SCA cada ~90 días (finmcp auth).
En Restricted Production solo se leen las cuentas que hayas vinculado (lista blanca) en el panel de Enable Banking.
El histórico disponible suele limitarse a ~90 días por las APIs PSD2 de los bancos.

Desarrollo

pip install -e ".[dev]"
pytest                       # suite de tests (analítica, mapper, sync, config)

La analítica son funciones puras testeadas contra una SQLite en memoria; el flujo de sync se prueba con un cliente falso (sin tocar el banco). CI en GitHub Actions corre la suite en Python 3.11–3.13 (.github/workflows/ci.yml).

Licencia

Available Tools

9 tools

get_balancesA

Saldo más reciente de cada cuenta.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full behavioral burden. It only states 'most recent balance' without clarifying update frequency, caching, authentication needs, or potential side effects. Minimal transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no unnecessary words. It is well front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The presence of an output schema mitigates the need to explain return values. However, the description does not cover behavioral context like time boundaries or error conditions. Adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist so schema coverage is 100%. Baseline 4 is appropriate. The description adds value by explaining the output (balances per account) beyond the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the most recent balance of each account. It uses a specific verb-resource combination and implicitly distinguishes from sibling tools like get_transactions and list_accounts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like get_transactions or list_accounts. The description lacks context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_transactionsB

Movimientos filtrados por cuenta, fechas (YYYY-MM-DD) y tipo (debit/credit).

ParametersJSON Schema

Name	Required	Description	Default
`end`	No
`type`	No
`limit`	No
`start`	No
`account_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description should disclose behavioral traits such as idempotency, pagination, or ordering. It only mentions filtering criteria but omits details about the limit parameter, default values, and whether the operation is read-only.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no redundant information. It efficiently communicates the core filters without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters, no annotations, and an output schema, the description is too brief. It lacks usage context, clarification on optional parameters, and differentiation from sibling tools. The output schema partially compensates for return value details, but overall completeness is low.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It adds meaning by specifying date format (YYYY-MM-DD) and allowed type values (debit/credit), covering account_id, start, end, and type. However, it does not explain the limit parameter or default behavior, leaving partial gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool filters transactions by account, date range (YYYY-MM-DD), and type (debit/credit). It uses a specific verb and resource, and distinguishes from sibling tools like 'get_balances' or 'list_accounts' that serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like 'search_transactions' or 'monthly_summary_tool'. The description only states what it does, not when to prefer it over siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_accountsB

Lista las cuentas bancarias sincronizadas.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but only states a simple action. No disclosure of read-only nature, authorization needs, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, front-loaded and efficient. However, it could include more useful information without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with an output schema, the description is minimally adequate but lacks any differentiation from siblings or behavioral details, especially given the absence of annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has zero parameters, so schema coverage is 100%. The description correctly implies no filters, meeting the baseline for a no-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists synchronized bank accounts, with a specific verb and resource. It is distinct from sibling tools like get_balances or get_transactions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description does not mention any context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_subscriptionsC

Cargos recurrentes detectados (suscripciones / domiciliaciones).

ParametersJSON Schema

Name	Required	Description	Default
`lookback_months`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It only states 'detected recurring charges' without explaining pagination, filtering, or what 'detected' implies (e.g., only active? past?). Minimal transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (5 words) but structurally incomplete—it is a phrase rather than a full sentence. While front-loaded, it omits critical information that the tool's limited size should have included.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the return values are partially covered, but the description fails to explain the parameter and usage context. For a simple tool with one optional parameter, this is insufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain the sole parameter 'lookback_months'. Its function and effect are left entirely to inference from the name and default value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists recurring charges (subscriptions/direct debits), using a specific noun phrase. However, it does not differentiate from sibling tools like get_transactions or unusual_charges, which might also deal with charges.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool over alternatives. The description does not mention conditions, prerequisites, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

monthly_summary_toolC

Resumen mensual: ingresos, gastos, neto, top comercios y categorías.

ParametersJSON Schema

Name	Required	Description	Default
`year`	Yes
`month`	Yes

TDQS

C2.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It only hints at output content but does not disclose any behavioral traits (e.g., read-only, auth requirements, rate limits, data freshness).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded with the key term 'Resumen mensual.' It conveys essential output components efficiently, though it could be slightly more structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and minimal parameter context, the description is insufficient. It does not specify output format, definitions (e.g., 'net'), or how 'top comercios' are determined.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage for parameters, and the description does not add any meaning beyond the schema. It does not explain valid ranges or formats for year and month.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it provides a monthly summary including income, expenses, net, top merchants, and categories. It distinguishes from sibling tools like get_transactions (which list individual transactions) and spend_by_category_tool (which focuses on category spending). However, it does not explicitly differentiate itself in the description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. It does not mention prerequisites, contexts, or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_transactionsA

Busca movimientos por texto en el comercio o el concepto.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose all behavioral traits. It states the search behavior (by text in merchant/concept) but omits details like case sensitivity, exact vs. partial matching, or whether pagination is supported beyond the limit parameter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the purpose. However, it could be slightly more structured by explicitly mentioning the parameters or result behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, return values need not be detailed. However, the description is minimal for a search tool with two parameters; it could mention the limit parameter's role or the scope of the search.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%; the description adds some meaning by specifying the fields searched (merchant and concept), but it does not explain the 'query' or 'limit' parameters beyond what the schema names imply. The description partially compensates for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches transactions by text in merchant or concept, which is a specific verb and resource. It easily distinguishes from sibling tools like get_transactions which likely lists all transactions without text filtering.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for text-based searching but provides no explicit guidance on when to use it versus alternatives (e.g., get_transactions for unfiltered lists). There are no when-not-to-use notes or sibling comparisons.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

spend_by_category_toolB

Gasto agregado por categoría en un periodo (fechas YYYY-MM-DD).

ParametersJSON Schema

Name	Required	Description	Default
`end`	No
`start`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must disclose all behavioral traits. It states it aggregates by category and uses date range, but fails to mention whether it is read-only, required permissions, or returns all categories. The basic behavior is clear but incomplete for a mutation-ambiguous tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that efficiently conveys the core purpose. No wasted words; front-loaded with action and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with an output schema, the description adequately covers purpose and parameter format. It could mention that it returns aggregated data but the output schema likely covers that. Slight gap in specifying whether all categories are included.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description compensates by specifying the date format ('YYYY-MM-DD') for the start and end parameters, adding meaning beyond the raw schema. However, it does not clarify if parameters are required or default behavior when omitted.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool aggregates spending by category over a date range, specifying verb ('aggregate') and resource ('spending by category'). It distinguishes from siblings like 'get_transactions' and 'monthly_summary_tool' but does not explicitly differentiate them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, such as when to prefer 'monthly_summary_tool' or 'get_transactions'. The description only implies usage for category-based period analysis without exclusions or context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sync_statusB

Estado de la última sincronización.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It only says 'status of last synchronization' without disclosing read-only nature, output format, or any side effects. With no output schema, the agent lacks behavioral details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no wasted words. It is appropriately sized for a tool with no parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, no output schema, no annotations), the description is minimally adequate. However, it could be more complete by describing the output (e.g., date, result) to fully inform the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema is empty (0 parameters), and schema coverage is 100%. The description adds no parameter semantics because none exist. Baseline for 0 params is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Estado de la última sincronización' clearly states the tool provides the status of the last synchronization. It distinguishes from financial sibling tools like get_balances or get_transactions. However, it is very brief and does not specify what the status entails (e.g., success/failure, timestamp).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention context, prerequisites, or exclusions. Usage is only implied by the tool name and sibling context (financial vs. sync).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

unusual_chargesC

Cargos atípicos respecto al histórico de cada comercio.

ParametersJSON Schema

Name	Required	Description	Default
`end`	No
`start`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden. It does not disclose whether the tool is read-only, the output format, or any side effects. The brief sentence only states the basic function without behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise at one sentence, but it is under-specified. It lacks front-loading of key details like parameters or usage context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 2 unannotated parameters and no parameter descriptions, the description is incomplete. It does not cover what the tool returns or how to use start/end. The existence of an output schema (not shown) may help but is not referenced.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description adds no meaning to the two parameters (start, end). It does not explain their role (e.g., date range) or format, leaving the agent to guess.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: detecting atypical charges compared to each merchant's historical data. The verb 'cargos atípicos' (atypical charges) combined with 'histórico' specifies the resource and behavior, making it distinct from generic transaction listing tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus siblings like 'search_transactions' or 'get_transactions'. The description lacks context about scenarios, prerequisites, or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

9 tool updatesv0.1.0Jul 12, 2026
- First observedget_balances
- First observedget_transactions
- First observedlist_accounts
- First observedlist_subscriptions
- First observedmonthly_summary_tool
- First observedsearch_transactions
- First observedspend_by_category_tool
- First observedsync_status
- First observedunusual_charges

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.3/5.0

Scored 2026-07-12 11:20 across 9 tools

Disambiguation5/5

Each tool targets a distinct function: account listing, balances, filtered transactions, subscriptions, monthly summary, text search, category spending, sync status, and unusual charges. There is no functional overlap.

Naming Consistency4/5

Most tools follow a verb_noun pattern in snake_case (e.g., get_balances, list_accounts). However, monthly_summary_tool and spend_by_category_tool include a '_tool' suffix not used by others, causing minor inconsistency.

Tool Count5/5

9 tools is appropriate for the domain. Each tool provides a specific capability without redundancy, covering account management, transaction analysis, subscriptions, and sync status.

Completeness4/5

The set covers core read-only banking operations: accounts, balances, transactions, subscriptions, and spending analysis. Missing is the ability to retrieve a single transaction detail, but overall it is reasonably complete for an analytics-focused MCP.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Synci AOAuth
io.synci
Read-only access to your bank, investment, and crypto accounts: balances, transactions, holdings.
Finance
52
Genie Expense TrackerOAuth
io.github.osamaadam
Read-only access to Genie accounts, transactions, investments, and financial summaries.
Finance
1
NevloOAuth
io.nevlo
Read bank accounts, balances and transactions from 10,000+ European banks.
Finance Data Platforms
2
fincontextOAuth
ai.fincontext
Read-only bank & investment accounts via Plaid: balances, holdings, transactions, SQL analytics.
Finance Databases
2

Related MCP Servers

Open Banking MCP Server
Finance
tkom04
A
license
C
quality
F
maintenance
Enables interaction with bank accounts via TrueLayer API, supporting listing accounts and retrieving transactions.
Updated a year ago (2025-09-20 16:38 UTC)
9
1
MIT
C6 Bank MCP
Finance Customer Data Platforms
mcp-dir
A
license
Not graded
quality
D
maintenance
Enables reading C6 Bank account balances, statements, credit card bills, and investments via Open Finance Brasil. It is read-only and regulated by the Central Bank of Brazil.
Updated 21 days ago (2026-08-30 19:38 UTC)
MIT
BankBridgeofficial
Finance Search
bankbridge-money
F
license
Not graded
quality
D
maintenance
Enables financial data access from connected bank accounts via MCP tools, allowing natural language queries about balances, transactions, subscriptions, investments, and more, with a focus on privacy and read-only access.
Updated 2 months ago (2026-07-10 19:44 UTC)
-
EU Open Banking MCP
Finance
cver-me
A
license
Not graded
quality
B
maintenance
Enables secure, read-only access to personal European bank accounts through Enable Banking and Cloudflare Workers, allowing MCP clients to list accounts, retrieve balances, search transactions, and summarize cash flow.
Updated 16 days ago (2026-09-05 16:07 UTC)
1
MIT

openbanking-mcp

Aviso

Arquitectura

Paso a paso

1. Instala el proyecto

2. Registra tu app en Enable Banking

3. Configura el .env

4. Elige tu banco

5. Autoriza y sincroniza

Comandos

Herramientas MCP (solo lectura)

Conectar a Claude Desktop

Conectar a ChatGPT

Categorías personalizadas

Importar histórico antiguo (CSV)

Sincronización programada (macOS / launchd)

Notas PSD2

Desarrollo

Licencia

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

BankBridgeofficial

3. Configura el `.env`