Skip to main content
Glama
Sign In
BankConv MCP server

BankConv MCP server

by wassim
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Save a conversion as a file

download_statement

Save a completed BankConv conversion as a CSV, OFX, QFX, QBO, or Xero file by conversion ID, returning the saved path and any warnings.

Instructions

Save an earlier BankConv conversion as a file on this computer, by its conversion id (from convert_statement or list_conversions). Returns the saved path and any warnings (for example a bank QuickBooks doesn't list), not the file contents. Uses no pages. csv: the statement as a spreadsheet; ofx: Xero, Sage, MYOB, QuickBooks Online; qfx: Quicken; qbo: QuickBooks Desktop (Web Connect); xero: Xero CSV with Xero's own columns. Errors say what went wrong: not_found for an unknown conversion id, gone once a conversion was deleted under data retention (24 hours by default), unreadable_statement when the tables can't be read as transactions (the message names the row), insufficient_credits when the account has too few pages.

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": {
      "conversion_id": "<conversion_id>",
      "format": "<format>"
    },
    "name": "download_statement"
  }
}

Input Schema

NameRequiredDescriptionDefault
formatYescsv: the statement as a spreadsheet; ofx: Xero, Sage, MYOB, QuickBooks Online; qfx: Quicken; qbo: QuickBooks Desktop (Web Connect); xero: Xero CSV with Xero's own columns.
tablesNoAdvanced: which tables to read, as page:table indexes from 0 ("0:1,1:0"). Leave out and BankConv picks the transaction tables.
save_toNoA file path or folder. Defaults to the Downloads folder (or the home folder), named after the original PDF. An existing file at that path is overwritten.
conversion_idYesThe conversion id, as returned by convert_statement or list_conversions.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.1
    • changedInput schema / properties / conversion_id / description
      Previous value: -"The conversion id."New value: +"The conversion id, as returned by convert_statement or list_conversions."
    • changedInput schema / properties / save_to / description
      Previous value: -"A file path or folder. Defaults to the current folder."New value: +"A file path or folder. Defaults to the Downloads folder (or the home folder), named after the original PDF. An existing file at that path is overwritten."
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Goes well past the annotations: it discloses the return shape (saved path plus warnings, NOT file contents), that no pages/credits are consumed, the 24-hour data-retention expiry, and four named error codes with the condition that triggers each. That is exactly the mutation/extension context the readOnlyHint=false / openWorldHint=true annotations leave unstated.

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?

Front-loaded with the core action and id source, then return shape, then formats, then errors — a sensible order. It is somewhat dense and duplicates the format enum strings already present in the schema, which is the one wasted block.

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 no output schema, the description steps in to describe the return value (path plus warnings, not contents) and enumerates the failure modes an agent must handle. For a 4-param file-writing tool that is sufficient to invoke and interpret it correctly.

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 schema already documents all four parameters, including the format enum and save_to's overwrite behavior. The description's format list is a near-verbatim restatement of the schema enum text and adds no syntax or defaults beyond it — baseline 3.

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?

Opening clause states a specific verb and resource — 'Save an earlier BankConv conversion as a file on this computer' — and immediately disambiguates from convert_statement (which produces the conversion) and list_conversions (which supplies ids). An agent can tell exactly which sibling this is not.

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 clearly frames this as a second step ('an earlier conversion', id from convert_statement or list_conversions), so the workflow position is explicit. It stops short of stating exclusions, e.g. that this cannot reproduce an expired conversion except via the 'gone' error note.

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

Deploy Server

Other Tools