Klarbon

Convert a bank statement

convert_bank_statement

Converts a bank statement file (CAMT.053, MT940, CODA, Norma 43, CFONB 120, BAI2, OFX, QIF and more) to another format such as CAMT.053, MT940, CSV or Excel, and checks that the balances reconcile. When the file leaves something open, such as the date order or the opening balance, the answer is a need: call again with the same file, the answer and the resume token. Costs 1 call per started 500 transactions from the account's API balance, or credits once the API balance is empty, charged only on success. A PDF statement or scan read automatically (beta, a draft to check) costs 5 calls per started 10 pages from the API balance, or 1 credit per started 10 pages once it cannot cover that. Needs an API key.

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": {
      "target": "<target>"
    },
    "name": "convert_bank_statement"
  }
}

Input Schema

Name	Required	Description
`resume`	No	The resume token from the last need answer.
`target`	Yes	A bank format id, such as camt-053, mt940, bank-csv or xlsx.
`account`	No	The answer to an account need, for a file with several accounts: the chosen account's position in the need's accounts list.
`century`	No	The answer to a century need: the century of the file's two-digit years.
`currency`	No	The answer to a currency need: an ISO 4217 code, for a file that states no currency.
`file_url`	No	A public https address of the file. Private and local addresses are refused.
`filename`	No	The file's name, which helps recognise its format.
`date_order`	No	The answer to a dateOrder need: how the file writes its dates.
`file_base64`	No	The file's bytes as base64. Give this or file_url.
`idempotency_key`	No	Any unique string. Calling again with the same key and arguments within 24 hours never charges again.
`opening_balance`	No	The answer to an openingBalance need: the opening balance the file does not print, as a decimal string.
`statement_number`	No	The statement number MT940 and CODA carry.
`decimal_separator`	No	The answer to a decimalSeparator need: the decimal separator of the file's amounts.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedNov 10, 2026

addedInput schema / properties / account / description

Added value: +"The answer to an account need, for a file with several accounts: the chosen account's position in the need's accounts list."

addedInput schema / properties / century / description

Added value: +"The answer to a century need: the century of the file's two-digit years."

addedInput schema / properties / currency / description

Added value: +"The answer to a currency need: an ISO 4217 code, for a file that states no currency."

addedInput schema / properties / date_order / description

Added value: +"The answer to a dateOrder need: how the file writes its dates."

addedInput schema / properties / decimal_separator / description

Added value: +"The answer to a decimalSeparator need: the decimal separator of the file's amounts."

addedInput schema / properties / opening_balance / description

Added value: +"The answer to an openingBalance need: the opening balance the file does not print, as a decimal string."

First observedNov 10, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) by disclosing the cost model (1 call per started 500 transactions, credits once the API balance is empty, charged only on success), the beta PDF path (5 calls per started 10 pages, draft output to check) and the API key requirement. That is exactly the pricing, auth and failure-cost context an agent needs before invoking a paid, open-world operation.

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?

Purpose and accepted formats are front-loaded, and every sentence carries information (formats, need loop, pricing, beta, auth). The pricing sentence is dense and slightly run-on, and the need-loop phrasing ('the answer is a need: call again...') takes a second pass to parse, but there is no filler.

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 13-parameter, no-output-schema tool this covers formats, the need/resume loop, cost, idempotency-adjacent charging and auth. The one real gap is what a successful call returns (a file, a link, a payload?) and how the reconciliation result is surfaced, which matters more than usual because there is no output schema.

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 100%, so the baseline is 3 and the schema already explains every parameter including the 'answer to a X need' fields. The description adds framing by explaining that needs are answered by re-calling with the resume token, but it adds no format or syntax detail beyond the 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?

Names a specific verb (converts) and resource (a bank statement file) and enumerates both source formats (CAMT.053, MT940, CODA, Norma 43, CFONB 120, BAI2, OFX, QIF) and targets (CAMT.053, MT940, CSV, Excel). It adds a second stated capability, balance reconciliation, so an agent knows this is convert-plus-validate rather than a pure format shifter, and the resource word 'bank statement' separates it from convert_invoice.

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?

Gives clear workflow guidance for the ambiguous case: when the file leaves something open (date order, opening balance), the answer is a 'need' and the agent must re-call with the same file, the answer and the resume token. It does not say when to prefer this over sibling tools such as list_formats or convert_invoice, but the usage context for the multi-call flow is explicit.

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

All Klarbon tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?