Skip to main content
Glama

banking.import_statement

Import one bank account's statement as CSV text (CSV today, PDF later) so the forecast starts from the bank's own balance. Owner or admin only. Stores each line and each day's closing balance for the account named by bank_label, account_last4 and currency; uploading the same statement again adds nothing. Name an account the same way every time (the label is matched ignoring case). Before anything is stored, only the last 4 digits of the account number are kept, and runs of 6 or more digits, email addresses and phone numbers are cut from descriptions and counterparties; payee and payer names stay as the statement gives them until the workspace is closed, when they are emptied and the lines are kept as figures and dates. The columns are recognised from the header (date, balance, and one signed amount or separate withdrawal and deposit columns); no bank layout is verified yet, so check the mapping in the reply. The latest balance, if under 31 days old, becomes the forecast's starting cash, graded 'statement', in place of a typed balance for the same account (a typed account whose label ends in other last 4 digits and dated on or after the statement is added to it, and the sum is graded 'declared'; an older one is left out until it is saved again with today's date), and the stored forecast is rerun. Returns counts, statement_balance, the mapping used, balance_checks, and forecast.status with next_step; verify with forecast.read. Refuses with FORBIDDEN SIMPLER_BANKING_ROLE_REFUSED for any other role (ask an owner or admin); VALIDATION_ERROR SIMPLER_BANKING_ACCOUNT_LAST4_INVALID when account_last4 has fewer than 4 digits (send the last 4 as text); VALIDATION_ERROR SIMPLER_BANKING_STATEMENT_FIELDS_INVALID naming each bad field; CONFLICT SIMPLER_BANKING_ACCOUNT_LABEL_CONFLICT with saved_accounts when an account with the same account_last4 and currency is saved under another bank_label, before anything is stored, because one account under two names would count its balance twice (resend with the saved bank_label for that account, or with new_account: true for a different account); VALIDATION_ERROR SIMPLER_BANKING_STATEMENT_UNPARSEABLE with reason and the file's columns when the columns or dates cannot be read (send mapping with 1-based column numbers, or date_order); PAYLOAD_TOO_LARGE SIMPLER_BANKING_STATEMENT_TOO_LARGE over 2,000,000 bytes or 20,000 lines (export a shorter date range); SERVICE_UNAVAILABLE SIMPLER_BANKING_STATEMENT_WRITE_FAIL (retry the same upload).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "csv_text": "<csv_text>",
      "bank_label": "<bank_label>",
      "account_last4": "<account_last4>",
      "currency": "<currency>"
    },
    "name": "banking.import_statement"
  }
}

Input Schema

NameRequiredDescriptionDefault
mappingNoOptional: 1-based column numbers, sent after a refusal lists the file's columns. Needs date and balance, plus amount (money in positive) or both debit and credit.
csv_textYesThe statement exported from online banking as CSV, at most 2,000,000 bytes. A title block above the header row is fine.
currencyYesThe account's currency.
bank_labelYesThe bank's name, such as DBS or Maybank. No account number.
date_orderNoOptional: send only when a refusal says every date can be read two ways. day_first reads 03/04/2026 as 3 April.
new_accountNoOptional: send true only after a SIMPLER_BANKING_ACCOUNT_LABEL_CONFLICT refusal, when this statement is from a different account that shares the saved account's last 4 digits and currency. Leave it out otherwise.
account_last4YesThe account number's last 4 digits as text, such as "0123". A longer number is cut to its last 4.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

With only readOnlyHint=false available, the description carries the full behavioral burden and does so extensively: role restrictions, idempotent storage, PII redaction before persistence, retention rules for payee/payer names, the 31-day balance cutoff, replacement/addition rules for typed balances, and forecast rerun behavior. It also lists concrete error codes and remedies.

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

Conciseness2/5

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

The description is a single dense paragraph of roughly 300 words, with return values, error codes, PII handling, and forecast rules packed together. Almost every sentence is informative, but the wall-of-text structure makes key calls to action and refusal remedies hard to scan.

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

Completeness5/5

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

There is no output schema, and the description fully explains the return payload (counts, statement_balance, mapping, balance_checks, forecast.status with next_step) and verification via forecast.read. It also covers refusal modes and their recovery paths, leaving little an agent needs to infer.

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 100%, so the baseline is 3, but the description adds operational meaning beyond the schema: mapping is a recovery path after an unparseable-column refusal, date_order is only for ambiguous dates, new_account is only for label conflicts, and account_last4 must be sent as text. The only gap is that it does not restate every parameter's role.

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 opening sentence names the exact action (import one bank account's statement as CSV text), the object (statement), and the downstream effect (forecast starts from the bank's own balance). It also distinguishes the format from the sibling statement_pdf by noting CSV today and PDF later.

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

Usage Guidelines4/5

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

It states owner/admin-only access, idempotent re-upload behavior, and when to send mapping, date_order, or new_account after specific refusals. It does not explicitly route the agent among siblings such as statement_pdf, statement_prepare, or forecast.run, though it points to forecast.read for verification.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources