Tallyproof Bank Statements

Convert bank statement

convert_bank_statement

Read-only

Use this when the user attaches a bank or credit card statement (text PDF, or the bank's CSV/Excel export) and wants it converted to Excel or CSV: "convert bank statement to excel", "bank statement pdf to csv", "import my statement into QuickBooks", "does my statement balance". Extracts each transaction (date, description, signed amount, running balance), reconciles opening + transactions = closing to the cent, points to missing or duplicated rows, suggests categories, and returns Excel, CSV and QuickBooks CSV downloads. Does not read scanned images (needs OCR first), does not connect to bank accounts, and is not for non-financial PDFs or general PDF editing.

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

Input Schema

Name	Required	Description
`file`	Yes	The statement to convert: a text PDF downloaded from the bank or card website, or the bank's CSV or Excel (.xlsx) transaction export, e.g. september-statement.pdf.
`date_order`	No	Order of numeric dates in a CSV/Excel export: MDY (US, 09/02/2026, default) or DMY (02/09/2026). Detected automatically when a day is above 12.
`flip_signs`	No	Only for CSV/Excel exports that list purchases as positive and payments as negative (common in credit card exports): true flips each amount so money out is negative. Default false.
`account_type`	No	auto (default): a PDF is classified from its text; pasted rows and CSV/Excel exports count as bank unless the balances or the sign pattern show a credit card (the result says so). bank: checking or savings. credit_card: charges are money out and the statement shows a previous and new balance owed. Example: credit_card.
`statement_year`	No	Closing year of the statement, used for dates printed without a year when the period is not on the file, e.g. 2026 (a December-January statement uses the January year).
`closing_balance`	No	Closing (ending or new) balance in dollars, e.g. 5034.47. Used with opening_balance to prove the total to the cent.
`opening_balance`	No	Opening (beginning or previous) balance in dollars, e.g. 4123.55. Only needed when the file has none, such as a CSV export without a balance column, or to override.

Output Schema

Name	Required	Description
`note`	Yes
`months`	Yes
`period`	Yes
`source`	Yes
`account`	Yes
`preview`	Yes
`warnings`	Yes
`downloads`	Yes
`categories`	Yes	Suggested categories from keyword rules; review before filing.
`transactions`	Yes
`reconciliation`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description goes well beyond them: it discloses the extraction fields, reconciliation to the cent, detection of missing or duplicated rows, category suggestions, and the three output formats returned. It also states hard limits (no OCR, no bank connection), so the agent knows precisely what will and will not happen.

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 lead sentence is front-loaded with the trigger, followed by the capabilities and then the exclusions in a sensible order. The example-phrase list is long but serves tool-selection matching; the only waste is mild redundancy between the example phrases and the prose that follows them.

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?

With an output schema present, return values need no explanation, and annotations cover safety; the description fills the remaining gaps by explaining inputs accepted, validation performed, failure modes (scanned images, duplicated rows), and output artifacts. Nothing an agent needs to call this correctly is missing.

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 enum and field semantics for date_order, flip_signs, account_type, statement_year, opening_balance, and closing_balance are already carried by structured data. The description adds value by explaining the reconciliation goal (opening + transactions = closing to the cent), which gives meaning to the two balance parameters, and by tying sign-flipping to credit card export conventions.

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 definition states a specific verb and resource (converting a bank/credit card statement into Excel, CSV, or QuickBooks CSV) and enumerates exactly what it extracts and validates. It never names the sibling summarize_transactions or explains how the two differ, so an agent has to infer the boundary from the word 'convert' alone.

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

Usage Guidelines5/5

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

The trigger condition is stated up front (user attaches a statement and wants conversion) with concrete example utterances that map directly onto request phrasings. Negative scope is equally explicit: no scanned images, no bank-account connection, no non-financial PDFs, no general PDF editing.

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

All Tallyproof Bank Statements 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?