Bankstatemently

Get Statement Data

get_statement

Read-only

Fetch the full converted data for a previously processed document. Use this after convert_statement returns a "processing" status, or to re-fetch results. output_format "json" (default) returns the data inline, renderable in chat. The other formats (csv, xlsx, qbo, xero) return a time-limited download link instead: present it as a normal link. data_mode selects which projection of the data you get: omit it for each output_format's existing default behavior. "normalized" is the cleaned, interpreted view; "original" includes each transaction's raw column values exactly as printed on the source PDF (originalData); "enhanced" is a reformatted view of the original columns (csv/xlsx only for now). Fetch data_mode: "original" when you plan to submit results to evaluate_benchmark — pass its originalData through verbatim; an absent originalData scores that benchmark's raw-fidelity dimension 0 for this document. Every response includes a "summary" field: use it as the single source of truth for what happened. If the conversation is not in English, translate it faithfully into the conversation language; never add details it doesn't contain. Never echo raw status values (e.g. "completed") or field names.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No	output_format "json" only. Max transactions to return (default 500, capped at 2000, or 500 with data_mode "original").
`offset`	No	output_format "json" only. Number of transactions to skip. Omit to start from the beginning.
`data_mode`	No	Omit for each output_format's existing default behavior (json: normalized; csv/xlsx: the export route's own default). "normalized": the cleaned, interpreted data. "original": includes each transaction's raw column values as printed on the source PDF (originalData) — fetch this before submitting to evaluate_benchmark. "enhanced": a reformatted view of the original columns; only available for output_format csv/xlsx today. qbo/xero always export normalized data — omit data_mode (or pass "normalized" explicitly) for those formats.
`document_id`	Yes	Document ID (from convert_statement or list_statements)
`output_format`	No	Output format	json

Output Schema

TableJSON Schema

Name	Required	Description	Default
`hint`	No
`error`	No
`gating`	No
`status`	Yes
`columns`	No
`message`	No
`results`	No
`summary`	No
`dataMode`	No
`document`	No
`warnings`	No
`exportUrl`	No
`documentId`	No
`extraction`	No
`pagination`	No
`processedAt`	No
`transactions`	No
`confidenceScore`	No
`processingTimeMs`	No
`transactionCount`	No

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed7 schema fields changedSep 4, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / properties / data_mode / description

Added value: +"Omit for each output_format's existing default behavior (json: normalized; csv/xlsx: the export route's own default). \"normalized\": the cleaned, interpreted data. \"original\": includes each transaction's raw column values as printed on the source PDF (originalData) — fetch this before submitting to evaluate_benchmark. \"enhanced\": a reformatted view of the original columns; only available for output_format csv/xlsx today. qbo/xero always export normalized data — omit data_mode (or pass \"normalized\" explicitly) for those formats."

addedInput schema / properties / document_id / description

Added value: +"Document ID (from convert_statement or list_statements)"

addedInput schema / properties / limit / description

Added value: +"output_format \"json\" only. Max transactions to return (default 500, capped at 2000, or 500 with data_mode \"original\")."

addedInput schema / properties / offset / description

Added value: +"output_format \"json\" only. Number of transactions to skip. Omit to start from the beginning."

addedInput schema / properties / output_format / description
```
Added value: +"Output format"
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changed5 schema fields changedAug 21, 2026

removedInput schema / properties / data_mode / description

Removed value: -"Omit for each output_format's existing default behavior (json: normalized; csv/xlsx: the export route's own default). \"normalized\": the cleaned, interpreted data. \"original\": includes each transaction's raw column values as printed on the source PDF (originalData) — fetch this before submitting to evaluate_benchmark. \"enhanced\": a reformatted view of the original columns; only available for output_format csv/xlsx today. qbo/xero always export normalized data — omit data_mode (or pass \"normalized\" explicitly) for those formats."

removedInput schema / properties / document_id / description

Removed value: -"Document ID (from convert_statement or list_statements)"

removedInput schema / properties / limit / description

Removed value: -"output_format \"json\" only. Max transactions to return (default 500, capped at 2000, or 500 with data_mode \"original\")."

removedInput schema / properties / offset / description

Removed value: -"output_format \"json\" only. Number of transactions to skip. Omit to start from the beginning."

removedInput schema / properties / output_format / description
```
Removed value: -"Output format"
```

Changed1 schema field changedAug 17, 2026

addedOutput schema / properties / results

Added value: +{
+  "items": {
+    "additionalProperties": {},
+    "properties": {
+      "content_hash": {
+        "type": "string"
+      },
+      "duplicate": {
+        "type": "boolean"
+      },
+      "error_code": {
+        "type": "string"
+      },
+      "status": {
+        "type": "string"
+      },
+      "upload_id": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "upload_id"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

First observedAug 12, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The annotations already declare readOnlyHint=true, so the description only needs to add non-obvious behavior. It discloses time-limited download links for non-json formats, the requirement to treat the response 'summary' field as the single source of truth, the translation rule, and the warning never to echo raw status values. These are meaningful behavioral details 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.

Conciseness5/5

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

The description is dense but every sentence earns its place: purpose, trigger condition, output format behavior, data_mode semantics, benchmark interaction, and response-handling rules. It is front-loaded with the core action and then layers dependent instructions in a logical order.

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 tool with 5 parameters, 100% schema coverage, and an output schema, the description covers all remaining contextual gaps: when to call it, what response shape to expect ('summary' field), how to handle non-json outputs, how to prepare for evaluate_benchmark, and cross-format constraints like qbo/xero always exporting normalized data. 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 description coverage is 100%, so the baseline is 3. The description adds value by explaining output_format behavior ('json returns data inline... other formats return a time-limited download link'), the data_mode projections, and the benchmark-specific requirement to fetch 'original' and pass originalData verbatim. It enriches the schema without replacing it.

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 first sentence states a specific verb and resource: 'Fetch the full converted data for a previously processed document.' This clearly distinguishes get_statement from siblings like convert_statement (which creates the processing) and list_transactions (which lists individual transactions). The title and name align with the described function.

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 gives explicit when-to-use guidance: 'Use this after convert_statement returns a "processing" status, or to re-fetch results.' It also names evaluate_benchmark and explains when to use data_mode "original". This is concrete routing against real sibling tools with no ambiguity.

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

All Bankstatemently tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation4/5

Core tools are cleanly separated by resource: statements, transactions, transfers, credits, and benchmark all have dedicated entry points. The five analytics tools (aggregate, group_by, compare, time_series, top_n) share metric/filter language, but their distinct output shapes and careful descriptions prevent major confusion, with only group_by vs. time_series/top_n occasionally overlapping.

Naming Consistency4/5

Most tools follow a clear snake_case verb_noun pattern such as convert_statement, list_transactions, rate_statement, and dismiss_statement. The analytics tools (aggregate, compare, group_by, time_series, top_n) break that pattern, but they are still recognizable, consistently styled, and form a meaningful cluster.

Tool Count4/5

At 16 tools, this is slightly above the typical 3-15 well-scoped range, but the server covers a broad workflow: upload, conversion, retrieval, categorization, analytics, transfer matching, rating, credits, and benchmarking. Each tool maps to a distinct capability, so the count feels justified rather than bloated.

Completeness4/5

The tool surface covers the full statement lifecycle from upload and conversion through retrieval, categorization, analysis, rating, and dismissal, plus useful side capabilities like credits and benchmark evaluation. Minor gaps exist—no permanent deletion and no way to manually edit category mappings—but dismiss_statement and categorize_statement provide adequate workarounds.

Get Statement Data

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

TDQS

Resources