Convert bank statement PDFs to Excel, CSV, OFX or QBO, every row checked against the balances.
Scored across 4 tools
Each tool targets a clearly distinct operation: verify (check_statement_balances), convert format (convert_statement), summarize analysis (summarise_spending), and reference lookup (list_supported_banks). There is no meaningful overlap in intent or output, so an agent can select the right tool unambiguously.
All four tools follow a consistent snake_case verb_noun pattern (check_statement_balances, convert_statement, list_supported_banks, summarise_spending). The only variation is British 'summarise' spelling, which is purely orthographic and does not break the pattern.
Four tools sit comfortably in the well-scoped range and each earns its place by covering a distinct capability (validation, conversion, summation, bank reference). No tool feels redundant or padded, and the surface is not so thin as to leave obvious gaps.
The core statement-processing lifecycle is covered: parse/verify, convert to many export formats, and summarize spending, plus a supporting bank list. Minor gaps exist around managing previously saved statements (e.g., listing or re-downloading past conversions), but these are workarounds rather than blockers.
Use this when the user asks whether a bank statement is complete, correct or genuine, or why its numbers do not add up. Reads the PDF and checks every row against the statement's own running balances: opening plus money in minus money out must land on the closing balance to the cent. Says whether it does, and names the rows where it breaks. Free with a PivotBank account.
| Name | Required | Description | Default |
|---|---|---|---|
| statement | No | The bank statement PDF the user shared. | |
| pdf_base64 | No | For clients without file attachments: the PDF, base64-encoded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, and the description adds real context on top: it reads the PDF, applies cent-level reconciliation, returns a yes/no verdict plus the specific rows that break, and notes the cost model ('Free with a PivotBank account'). It stops short of covering malformed PDFs or statements lacking a running-balance column.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: trigger first, mechanism second, output and pricing last. No redundancy, no restatement of the tool name, and the most decision-relevant information (when to invoke) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only validation tool with no output schema, the description covers what is checked, what is returned, and the pricing/auth caveat. The one gap is edge-case behavior when a statement has no running-balance column to reconcile against, which an agent might need to set expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the nested statement object (file_id, file_name, mime_type, download_url) and the pdf_base64 fallback are already fully documented in the schema. The description only says 'Reads the PDF' without adding format constraints, size limits, or guidance on choosing the attachment path over base64, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: it reads a bank statement PDF and reconciles every row against the statement's own running balances, with the exact arithmetic rule spelled out (opening + in - out = closing, to the cent). This is clearly distinct from siblings convert_statement and summarise_spending, which transform or aggregate rather than validate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit triggering condition: use when the user asks whether a statement is complete, correct, genuine, or why its numbers don't add up. It does not name the alternatives (e.g. convert_statement for format changes, summarise_spending for totals) or state when this tool is the wrong choice, but the positive routing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants a bank statement or credit card statement PDF turned into a spreadsheet: Excel (xlsx), CSV, QuickBooks (QBO), Xero (OFX), Quicken (QIF) or JSON. Reads every transaction (date, description, money in, money out, balance) and checks them against the statement's own running balances, so the reading is proved rather than guessed. Saves the statement to the user's PivotBank account and returns a link to download it in any of those formats. Needs the user to sign in to PivotBank; agents may instead send a Pro API key as 'Authorization: Bearer pvb_live_...'.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | No | The file name, for your own records. | |
| statement | No | The bank statement PDF the user shared. | |
| pdf_base64 | No | For clients without file attachments: the statement PDF, base64-encoded. 15 MB before encoding at most. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the safety profile (non-readonly, non-destructive, non-idempotent, closed-world). The description adds substantive behavior beyond them: it discloses the verification step against running balances, the side effect of saving the statement to the user's account, the returned download link, and two authentication paths (user sign-in or a Bearer API key). That is exactly the extra context an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the trigger, then behavior, then auth. Every sentence carries information, though the format list is repeated twice (once as output formats, once as 'any of those formats'), which is mild redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description covers the return value (a download link usable in any listed format), the auth requirements, the verification behavior, and the storage side effect. An agent has everything needed to invoke it correctly and set user expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and all three parameters (filename, statement nested object, pdf_base64) are documented in the schema, including the 15 MB base64 limit and the 'clients without attachments' case. The description adds no parameter-level detail beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (convert a bank/credit card statement PDF) and enumerates the exact output formats (xlsx, CSV, QBO, OFX, QIF, JSON). This is clearly distinguishable from siblings like check_statement_balances and summarise_spending, which operate on the statement rather than convert it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Opens with an explicit trigger: 'Use this when the user wants a bank statement or credit card statement PDF turned into a spreadsheet.' That gives a clear when-to-use context, but it never names an alternative tool or states when NOT to use this one, so routing between it and the balance-checking sibling is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the banks PivotBank recognises by name, for one country (ISO 3166 alpha-2, e.g. GB, US, ZA) or for all. A statement from a bank not listed still converts: the reader works from the layout, not a per-bank template.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ISO 3166 alpha-2 code. Leave out for every bank. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond them: recognition is name-based only and non-listed banks are still convertible because parsing uses layout, not a per-bank template.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler. The scope statement leads and the reassuring caveat follows, which is the right ordering for an agent deciding whether to call it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single optional-parameter read tool with annotations covering safety and no output schema, the definition is essentially complete. It only omits the return shape (a plain list of bank names), which is minor given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 goes beyond it by giving concrete ISO alpha-2 examples (GB, US, ZA) and restating the omit-for-all semantics in the tool's own framing. Marginal but genuine added meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Lists the banks PivotBank recognises by name') plus the scope dimension (one country or all). No sibling overlap exists among convert_statement/check_statement_balances/summarise_spending, so no differentiation is needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tells the agent the two calling modes (single country vs all) and, more importantly, pre-empts an incorrect use case by stating a statement from an unlisted bank still converts. No explicit when-not for the broader workflow, but the key mis-invocation is ruled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants to know where their money went from a bank statement PDF: money in and out, spending by category, top merchants and repeating payments such as subscriptions. Free with a PivotBank account.
| Name | Required | Description | Default |
|---|---|---|---|
| statement | No | The bank statement PDF the user shared. | |
| pdf_base64 | No | For clients without file attachments: the PDF, base64-encoded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds only the 'Free with a PivotBank account' cost/auth context, and says nothing about processing time, page limits, or what happens with unsupported statements. Useful but thin beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single well-formed sentence that front-loads the usage trigger and then lists the outputs. No wasted filler; the trailing pricing note is the only element of marginal value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully enumerates the returned analysis categories, and annotations carry the safety profile. It is nearly complete, lacking only edge-case behavior (unsupported PDFs, empty categories) for a nested-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both inputs (the statement object and pdf_base64) are already documented by the schema. The description mentions the 'bank statement PDF' but adds no guidance on when to use the file object versus the base64 fallback, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (summarise) and resource (bank statement PDF) and enumerates the outputs: money in/out, spending by category, top merchants, repeating payments. That is enough to distinguish it from convert_statement and list_supported_banks, though it never names the nearest sibling check_statement_balances, which also deals with statement figures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit triggering condition: 'Use this when the user wants to know where their money went from a bank statement PDF.' That is clear context for invocation. It offers no exclusions or alternatives (e.g., when to prefer check_statement_balances), so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_statement_balancesconvert_statementlist_supported_bankssummarise_spendingConvert PDF bank statements to checked Excel, CSV or JSON with balance validation.
Turn bank statement PDFs into categorized, balance-checked transactions and reports.
Convert PDF bank statements into structured transactions, accounts, and balances.
Turn bank statement PDFs, CSVs, XLSX and OFX into categorised transactions plus a summary.
Add one secure layer between your agents and this server.
