Bankstatemently

Match Transfers Between Accounts

list_transfers

Read-only

Match transfers between your own accounts. A transfer is TWO transactions — a debit leaving one of your accounts and a credit arriving in another — matched as two sides of the same movement (amount and date aligned); account-level successions (an account closing into a successor) are matched too. A payment to an outside party is not a transfer here: only movements with both sides visible in your statements are matched. THE way to answer any "was money moved between my accounts" / "did I transfer X" question — never try to answer a money-moved-between-accounts question with list_transactions + arithmetic; always call this tool instead. Scope defaults to all your completed statements; pass "scope" to narrow to specific accounts/products and/or a date range. Every response reports the match window (in days) it used, even when no transfers are found — a lack of matches is never silent about how hard it looked. To find large movements with NO matching counterpart in your other accounts — e.g. "trace transfers over $10,000; which ones leave without a known destination?" — pass "amountMin": reconciled pairs and successions are filtered to that floor, and the response gains an "unmatched" bucket of large movements (debits leaving, or unexplained credits arriving) with no matching pair, candidate, or succession. Omit amountMin for the ordinary reconciled-pairs answer.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`scope`	No	Optional structural scope (WHO × WHEN). Omit to search across all your completed statements. "accounts" is a list of account/product chips (kind + identityKey); "dateRange" bounds by transaction date (YYYY-MM-DD).
`amountMin`	No	Inclusive minimum absolute amount. When present, transfers/accountSuccessions are floored to this amount and the response gains an "unmatched" bucket of large movements with no matching counterpart. Omit for the ordinary reconciled-pairs answer.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`scope`	Yes
`ambiguous`	Yes
`transfers`	Yes
`unmatched`	No
`ambiguousCount`	Yes
`matchWindowDays`	Yes
`accountSuccessions`	Yes

Schema Changelog

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

Changed10 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 / amountMin / description

Added value: +"Inclusive minimum absolute amount. When present, transfers/accountSuccessions are floored to this amount and the response gains an \"unmatched\" bucket of large movements with no matching counterpart. Omit for the ordinary reconciled-pairs answer."

addedInput schema / properties / scope / description

Added value: +"Optional structural scope (WHO × WHEN). Omit to search across all your completed statements. \"accounts\" is a list of account/product chips (kind + identityKey); \"dateRange\" bounds by transaction date (YYYY-MM-DD)."

addedInput schema / properties / scope / properties / accounts / description

Added value: +"Account/product chips (kind + identityKey) to scope to. Empty = all accounts."

removedInput schema / properties / scope / properties / accounts / items / anyOf

Removed value: -[
-  {
-    "properties": {
-      "anchorContentHash": {
-        "type": "string"
-      },
-      "identityKey": {
-        "minLength": 1,
-        "type": "string"
-      },
-      "kind": {
-        "const": "account",
-        "type": "string"
-      },
-      "label": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "kind",
-      "identityKey"
-    ],
-    "type": "object"
-  },
-  {
-    "properties": {
-      "identityKey": {
-        "minLength": 1,
-        "type": "string"
-      },
-      "kind": {
-        "const": "product",
-        "type": "string"
-      },
-      "label": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "kind",
-      "identityKey"
-    ],
-    "type": "object"
-  }
-]

addedInput schema / properties / scope / properties / accounts / items / oneOf

Added value: +[
+  {
+    "properties": {
+      "anchorContentHash": {
+        "description": "Document-anchored lookup when present (results page); omit for a user-scoped lookup (workspace surfaces).",
+        "type": "string"
+      },
+      "identityKey": {
+        "description": "Canonical account identity key (accountIdentityKey), never a raw DB UUID.",
+        "minLength": 1,
+        "type": "string"
+      },
+      "kind": {
+        "const": "account",
+        "description": "This chip addresses a single account.",
+        "type": "string"
+      },
+      "label": {
+        "description": "Display label for this chip.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "kind",
+      "identityKey"
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "identityKey": {
+        "description": "Product slug.",
+        "minLength": 1,
+        "type": "string"
+      },
+      "kind": {
+        "const": "product",
+        "description": "This chip addresses a product and expands to its child accounts.",
+        "type": "string"
+      },
+      "label": {
+        "description": "Display label for this chip.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "kind",
+      "identityKey"
+    ],
+    "type": "object"
+  }
+]

addedInput schema / properties / scope / properties / dateRange / description

Added value: +"Bounds results to transactions within this date range. Omit for no date filter."

addedInput schema / properties / scope / properties / dateRange / properties / from / description
```
Added value: +"Start of the date range (inclusive), YYYY-MM-DD."
```
addedInput schema / properties / scope / properties / dateRange / properties / to / description
```
Added value: +"End of the date range (inclusive), YYYY-MM-DD."
```

changedOutput schema / $schema

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

Changed8 schema fields changedAug 21, 2026

removedInput schema / properties / amountMin / description

Removed value: -"Inclusive minimum absolute amount. When present, transfers/accountSuccessions are floored to this amount and the response gains an \"unmatched\" bucket of large movements with no matching counterpart. Omit for the ordinary reconciled-pairs answer."

removedInput schema / properties / scope / description

Removed value: -"Optional structural scope (WHO × WHEN). Omit to search across all your completed statements. \"accounts\" is a list of account/product chips (kind + identityKey); \"dateRange\" bounds by transaction date (YYYY-MM-DD)."

removedInput schema / properties / scope / properties / accounts / description

Removed value: -"Account/product chips (kind + identityKey) to scope to. Empty = all accounts."

addedInput schema / properties / scope / properties / accounts / items / anyOf

Added value: +[
+  {
+    "properties": {
+      "anchorContentHash": {
+        "type": "string"
+      },
+      "identityKey": {
+        "minLength": 1,
+        "type": "string"
+      },
+      "kind": {
+        "const": "account",
+        "type": "string"
+      },
+      "label": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "kind",
+      "identityKey"
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "identityKey": {
+        "minLength": 1,
+        "type": "string"
+      },
+      "kind": {
+        "const": "product",
+        "type": "string"
+      },
+      "label": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "kind",
+      "identityKey"
+    ],
+    "type": "object"
+  }
+]

removedInput schema / properties / scope / properties / accounts / items / oneOf

Removed value: -[
-  {
-    "properties": {
-      "anchorContentHash": {
-        "description": "Document-anchored lookup when present (results page); omit for a user-scoped lookup (workspace surfaces).",
-        "type": "string"
-      },
-      "identityKey": {
-        "description": "Canonical account identity key (accountIdentityKey), never a raw DB UUID.",
-        "minLength": 1,
-        "type": "string"
-      },
-      "kind": {
-        "const": "account",
-        "description": "This chip addresses a single account.",
-        "type": "string"
-      },
-      "label": {
-        "description": "Display label for this chip.",
-        "type": "string"
-      }
-    },
-    "required": [
-      "kind",
-      "identityKey"
-    ],
-    "type": "object"
-  },
-  {
-    "properties": {
-      "identityKey": {
-        "description": "Product slug.",
-        "minLength": 1,
-        "type": "string"
-      },
-      "kind": {
-        "const": "product",
-        "description": "This chip addresses a product and expands to its child accounts.",
-        "type": "string"
-      },
-      "label": {
-        "description": "Display label for this chip.",
-        "type": "string"
-      }
-    },
-    "required": [
-      "kind",
-      "identityKey"
-    ],
-    "type": "object"
-  }
-]

removedInput schema / properties / scope / properties / dateRange / description

Removed value: -"Bounds results to transactions within this date range. Omit for no date filter."

removedInput schema / properties / scope / properties / dateRange / properties / from / description
```
Removed value: -"Start of the date range (inclusive), YYYY-MM-DD."
```
removedInput schema / properties / scope / properties / dateRange / properties / to / description
```
Removed value: -"End of the date range (inclusive), YYYY-MM-DD."
```

Changed2 schema fields changedAug 13, 2026

addedInput schema / properties / amountMin

Added value: +{
+  "description": "Inclusive minimum absolute amount. When present, transfers/accountSuccessions are floored to this amount and the response gains an \"unmatched\" bucket of large movements with no matching counterpart. Omit for the ordinary reconciled-pairs answer.",
+  "type": "number"
+}

addedOutput schema / properties / unmatched

Added value: +{
+  "additionalProperties": {},
+  "properties": {},
+  "type": "object"
+}

First observedAug 12, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already say readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds substantial behavioral context: scope defaults to all completed statements, every response reports the match window even when no transfers are found, and amountMin changes the response to include an unmatched bucket. No contradiction with 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 longer than typical, but every sentence earns its place: definition, exclusion, usage rule, default scope, match-window transparency, and amountMin's unmatched mode. The core definition is front-loaded, and there is no filler or repetition beyond what aids clarity.

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?

Given nested scope objects, a special amountMin mode, and an output schema, the description is remarkably complete. It covers defaults, negative cases like no transfers found, the matched/unmatched distinction, and how the tool behaves when narrowed. An agent has enough context to select and invoke this tool correctly without further inference.

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% and the schema already documents scope, accounts chips, dateRange, and amountMin in detail. The description adds meaningful usage semantics such as the default scope behavior and the dual-mode behavior of amountMin, but the schema is already doing heavy lifting for structural meaning. This is complementary rather than essential, so slightly below top score.

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 and resource: 'Match transfers between your own accounts.' It defines a transfer as two sides of the same movement, explicitly excludes payments to outside parties, and differentiates this tool from list_transactions by saying arithmetic with list_transactions should never be used instead. This makes the tool's purpose unmistakable.

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?

It explicitly states this is 'THE way to answer any' money-moved-between-accounts question, tells the agent to never use list_transactions + arithmetic, and even explains when to add amountMin for unmatched large movements. This gives clear when-to-use and when-not-to-use guidance, plus a direct alternative to avoid.

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.

Match Transfers Between Accounts

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

TDQS

Resources