Skip to main content
Glama
popechia

ABANCA MCP Server

by popechia
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

ABANCA MCP Server

Servidor Model Context Protocol (MCP) para conectar la API de OpenBanking de ABANCA (PSD2) con LLMs como Claude, ofreciendo acceso seguro a cuentas y movimientos bancarios.

Requisitos

  • Node.js 18+

  • Credenciales OpenBanking de ABANCA (CLIENT_ID y CLIENT_SECRET).

  • Una clave secreta de encriptación de 32 caracteres exactos para un almacenamiento seguro local de los tokens OAuth.

Related MCP server: Banco MCP

Instalación

  1. Clona/Instala este repositorio y entra en el directorio.

  2. Instala las dependencias: npm install

  3. Compila el código: npm run build

  4. Renombra .env.example a .env y rellena las variables:

    • CLIENT_ID

    • CLIENT_SECRET

    • ENCRYPTION_KEY: Ejemplo 12345678901234567890123456789012 (Debe ser de 32 caracteres exactos)

    • PORT: (Opcional) el puerto local para el inicio de sesión OAuth, default 3000.

Uso en Claude Desktop

Al ejecutarse vía stdio, no hace falta que inicies el servidor manualmente si usas un cliente MCP. Añádelo a la configuración de tu Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "abanca": {
      "command": "node",
      "args": ["/home/pope/desarrollo/antigravity/apiABANCA/build/index.js"],
      "env": {
        "CLIENT_ID": "tu_client_id_real",
        "CLIENT_SECRET": "tu_client_secret_real",
        "ENCRYPTION_KEY": "tu_clave_de_32_caracteres_secreta"
      }
    }
  }
}

Nota: Asegúrate de reiniciar Claude Desktop si realizas cambios en el archivo de configuración.

Seguridad y Flujo de Autenticación

  • OAuth Efímero: En el primer uso (cuando el servidor arranque desde Claude y no encuentre tokens locales), creará temporalmente un servidor Express en el puerto 3000 y pedirá por consola de error (stderr) que visites una URL en el navegador. Claude captura los logs stderr y te mostrará el enlace.

  • Tras el login exitoso, el servidor guardará los tokens AES-256-GCM y apagará el servidor Express automáticamente para limitar vectores de ataque.

  • Minimización de datos: Las peticiones de la API están desgranadas para proveer sólo cuenta y saldos o movimientos simplificados de cara a evitar que el LLM sufra saturación de contexto de variables no utilizables de la API bancaria originaria.

Available Tools

2 tools
get_account_transactionsC

Retrieves the transactions for a specific bank account IBAN.

ParametersJSON Schema
NameRequiredDescriptionDefault
ibanYesThe IBAN of the account to fetch transactions for
days_agoNoNumber of days of history to fetch (default: 30)

TDQS

C2.9/5.0
Behavior2/5

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

No annotations provided, so description carries full burden. It discloses only the basic read operation ('Retrieves') but omits critical financial API behaviors: pagination limits, rate limiting, data freshness/real-time vs cached status, authentication requirements, or error handling for invalid IBANs.

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?

Single 9-word sentence is efficient and front-loaded (verb first). No redundancy or fluff. However, for a financial data tool handling sensitive transaction history, this brevity may be excessive minimalism that sacrifices necessary behavioral context.

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?

With 100% schema coverage and only 2 simple parameters (one optional), the description is minimally adequate for invocation. However, lacking output schema and annotations, and given this retrieves financial transaction data, the description is incomplete regarding data volume, format expectations, and result set boundaries.

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 coverage is 100% with both 'iban' and 'days_ago' fully documented in the schema. The description mentions IBAN generically but does not add param-specific semantics, syntax guidance, or usage notes beyond what the schema already provides. Baseline 3 appropriate for high schema coverage.

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 uses specific verb 'Retrieves' and resource 'transactions' with scope 'for a specific bank account IBAN'. However, it does not explicitly distinguish from sibling tool 'get_bank_accounts' (which likely lists accounts vs. this retrieving transaction history for a specific account).

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 provided on when to use this tool versus alternatives, nor prerequisites (e.g., suggesting users may need 'get_bank_accounts' first to obtain valid IBANs). The description is purely functional with no contextual usage hints.

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

get_bank_accountsB

Retrieves a list of bank accounts and their balances.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of disclosure. It provides minimal behavioral context by mentioning 'balances' (indicating account-level financial data is returned), but lacks details on pagination, authentication requirements, rate limits, or the complete structure of the returned data.

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 single-sentence description is efficient at 9 words, front-loaded with the action ('Retrieves'), and contains no extraneous text. However, similar to the calibration example, it doesn't quite achieve a 5 as it could slightly improve by noting the unfiltered nature of the retrieval given the empty parameter schema.

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 tool with zero parameters and no output schema, the description provides the minimum viable context by identifying the resource type and key returned attribute (balances). However, given the lack of structured output schema, it should ideally describe the return format (e.g., list of objects with account IDs and balances) to be considered complete.

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?

Per the rubric, 0 parameters equals a baseline score of 4. The description appropriately does not attempt to invent parameter semantics, though it could have noted 'accepts no filters' or 'retrieves all accessible accounts' to clarify the empty schema behavior.

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 uses a specific verb ('Retrieves') and resource ('bank accounts'), and mentions 'balances' which distinguishes it from the sibling tool 'get_account_transactions' (accounts vs. transactions). However, it does not explicitly reference the sibling relationship or when to choose one over the other, which prevents a 5.

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 states what the tool does but provides no guidance on when to use it versus alternatives, prerequisites (e.g., authentication), or exclusion criteria. The distinction from 'get_account_transactions' must be inferred from the resource names rather than explicit guidance.

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.

  1. 2 tool updatesv1.0.0
    • First observedget_account_transactions
    • First observedget_bank_accounts
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.1/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one retrieves a list of bank accounts with balances, while the other retrieves transactions for a specific account. There is no overlap or ambiguity in their functions, making it easy for an agent to select the correct tool based on the need.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern with 'get_' prefix, using snake_case throughout. The naming is predictable and readable, with no deviations or mixed conventions, ensuring clarity and ease of use.

Tool Count2/5

With only two tools, the server feels under-scoped for a banking domain that typically involves operations like creating accounts, updating details, or initiating transfers. This limited set may hinder agents from performing comprehensive banking tasks, indicating a mismatch with the apparent scope.

Completeness2/5

The tool surface is severely incomplete for a banking server, covering only retrieval of accounts and transactions. Missing are essential CRUD operations such as creating or updating accounts, initiating transfers, or managing payments, which are critical for typical banking workflows and will likely cause agent failures.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • BankSync MCP Server

    banksynchq
    A
    license
    Not graded
    quality
    C
    maintenance
    Connect AI agents to real bank accounts across 15,000+ financial institutions for transactions, balances, investments, and loans.
    2
    MIT

  • Banco MCP

    douglac
    A
    license
    Not graded
    quality
    F
    maintenance
    Connects Brazilian banks (Itaú, Bradesco, Nubank, etc.) to AI agents, enabling natural language queries about expenses, statements, investments, and credit cards via regulated Open Finance.
    22
    MIT

  • Caixa Econômica Federal MCP

    mcp-dir
    A
    license
    Not graded
    quality
    D
    maintenance
    Connects Claude, ChatGPT, and other AI agents to Caixa Econômica Federal accounts via Open Finance Brasil, enabling natural language queries about balances, transactions, credit card bills, and investments in read-only mode.
    MIT

  • RecargaPay MCP

    mcp-dir
    A
    license
    Not graded
    quality
    D
    maintenance
    Connects RecargaPay accounts to AI agents via Open Finance Brasil, enabling read-only queries about balances, statements, credit card bills, and investments in natural language.
    MIT