bankstatementparser-mcp

Validate statement (dry run)

validate_statement

Read-onlyIdempotent

Validate a bank statement payload for well-formedness before full parsing. Returns pass/fail with transaction count and format, without exposing transaction rows.

Instructions

Dry-run parse an inline statement to check it parses cleanly.

Use this to confirm a payload is well-formed and parseable before
committing to a full read; it returns a structured pass/fail with the
transaction count but never the rows themselves, and never raises on a
parse error. To actually read the transactions use ``parse_statement``.

Args:
    content: The raw statement text.
    filename: Original filename; its extension selects the format.
    format: Explicit format override.

Returns:
    A dict with ``is_valid``, the resolved ``format``, the
    ``transaction_count`` on success, and an ``error`` on failure.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`format`	No	Explicit format identifier that overrides detection from the filename. Must be exactly one of: 'camt', 'pain001', 'csv', 'ofx', 'qfx', 'mt940' (see list_supported_formats). When omitted, the format is inferred from the filename extension.
`content`	Yes	The raw statement text to validate, inline (not a file path). Accepts ISO 20022 CAMT.053 and pain.001 XML, SWIFT MT940, CSV exports, and OFX/QFX payloads.
`filename`	No	Original filename of the payload; its extension (.xml, .csv, .ofx, .qfx, .mt940, .sta) selects the format when 'format' is omitted. Defaults to 'statement.xml'.	statement.xml

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.0.19Sep 1, 2026

changedInput schema / properties / format / description

Previous value: -"Explicit format identifier that overrides detection from the filename. Must be exactly one of: 'camt', 'csv', 'mt940', 'ofx', 'pain001', 'qfx' (see list_supported_formats). When omitted, the format is inferred from the filename extension."New value: +"Explicit format identifier that overrides detection from the filename. Must be exactly one of: 'camt', 'pain001', 'csv', 'ofx', 'qfx', 'mt940' (see list_supported_formats). When omitted, the format is inferred from the filename extension."

changedInput schema / properties / format / enum

Previous value: -[
-  "camt",
-  "csv",
-  "mt940",
-  "ofx",
-  "pain001",
-  "qfx"
-]New value: +[
+  "camt",
+  "pain001",
+  "csv",
+  "ofx",
+  "qfx",
+  "mt940"
+]

Changed2 schema fields changedJul 29, 2026

changedInput schema / properties / format / description

Previous value: -"Explicit format identifier that overrides detection from the filename. One of: 'camt' (CAMT.053), 'pain001', 'csv', 'ofx', 'qfx', 'mt940'. When omitted, the format is inferred from the filename extension."New value: +"Explicit format identifier that overrides detection from the filename. Must be exactly one of: 'camt', 'csv', 'mt940', 'ofx', 'pain001', 'qfx' (see list_supported_formats). When omitted, the format is inferred from the filename extension."

addedInput schema / properties / format / enum

Added value: +[
+  "camt",
+  "csv",
+  "mt940",
+  "ofx",
+  "pain001",
+  "qfx"
+]

Changed3 schema fields changedv0.0.16Jul 10, 2026

addedInput schema / properties / content / description

Added value: +"The raw statement text to validate, inline (not a file path). Accepts ISO 20022 CAMT.053 and pain.001 XML, SWIFT MT940, CSV exports, and OFX/QFX payloads."

addedInput schema / properties / filename / description

Added value: +"Original filename of the payload; its extension (.xml, .csv, .ofx, .qfx, .mt940, .sta) selects the format when 'format' is omitted. Defaults to 'statement.xml'."

addedInput schema / properties / format / description

Added value: +"Explicit format identifier that overrides detection from the filename. One of: 'camt' (CAMT.053), 'pain001', 'csv', 'ofx', 'qfx', 'mt940'. When omitted, the format is inferred from the filename extension."

First observedv0.0.14Jul 9, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already cover read-only, idempotent, non-destructive, and closed-world behavior. The description adds valuable behavioral context beyond those flags: it never raises on parse error, returns a structured pass/fail, includes transaction count on success, and never returns row data. This meaningfully informs agent expectations around failure handling and output scope.

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

Conciseness5/5

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

The description is well-structured with a clear purpose statement, usage guidance, Args, and Returns sections. Every sentence earns its place, and the most important behavioral constraints (no rows, no raise) are front-loaded before the alternative tool mention.

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?

For a validation tool with rich annotations, a fully described schema, an output schema, and explicit sibling guidance, the description is complete. An agent knows what it validates, when to call it, what it returns, how it behaves on failure, and which sibling to use when actual data is needed.

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 fully documents content, filename, and format. The description's Args section largely restates this existing information without adding new semantic depth beyond what the schema already provides. This is the appropriate baseline for a fully self-documenting 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?

The description uses a specific verb-resource pair ('Dry-run parse an inline statement') and immediately clarifies what it does and does not return (pass/fail with transaction count, never rows). It also distinguishes itself from parse_statement by naming it explicitly, so an agent can separate the two tools without opening their schemas.

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 description states exactly when to use this tool: to confirm a payload is well-formed before committing to a full read. It also names the alternative action ('To actually read the transactions use parse_statement'), which provides an explicit selection rule between siblings.

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

Deploy Server