Bankstatemently

List Money That Left Your Accounts

list_outflows

Read-only

Every debit that left your accounts — in no confirmed transfer between your own accounts, and not a fee — each in ONE destination whose kind is also its next step: "own-account" (a printed account mask that names one of your accounts and no matched credit was found: ask for that account's statement), "account" (a printed account mask for an account outside your statements: request that account's statements; an in-kind move such as securities, crypto or escrow starts as a wire to that account and becomes visible only once the receiving statement is uploaded), "cash" (cash out: where it went cannot be followed, so the cumulative amount is the finding), "name" (a named party: review whether it was household spending) and "unknown" (nowhere the line says; kept visible, one entry per line, never merged). A destination carries the cumulative amount sent, per currency, never a balance. "mayBeOwnAccount" lists debits in an open candidate pair ("may be a move between your own accounts") apart, in no total. "unresolved" lists debits whose documents conflict about where they went (a transfer term and a payment term, no category to settle it) apart, in no total: the documents do not say where they went, so say so and ask the person to confirm. THE way to answer "did money disappear from my accounts, and where do I look next" — never answer it by summing list_transactions rows. Pass "dateRange" ({ from, to }, inclusive, YYYY-MM-DD) to report only debits in that range, for example from a separation date: transfers are matched over the whole scope first, so a transfer whose credit lies outside the range is still a transfer, never an outflow. Scope defaults to all your completed statements; pass "scope" to narrow to specific accounts/products and/or a date range (a scope date range also narrows what is matched — prefer "dateRange").

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: "account" \| "product", id }, the id of an account descriptor or product returned by a tool); "dateRange" bounds by transaction date (YYYY-MM-DD).
`dateRange`	No	Report only debits dated in this inclusive range. Omit to report every date.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`scope`	Yes
`dateRange`	Yes
`unresolved`	Yes
`destinations`	Yes
`mayBeOwnAccount`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 10, 2026

addedOutput schema / properties / destinations / items / properties / identifiers

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

changedOutput schema / properties / destinations / items / required

Previous value: -[
-  "kind",
-  "label",
-  "totals",
-  "outflows"
-]New value: +[
+  "kind",
+  "label",
+  "identifiers",
+  "totals",
+  "outflows"
+]

addedOutput schema / properties / unresolved

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "account": {
+        "additionalProperties": false,
+        "properties": {
+          "id": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "label": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "label"
+        ],
+        "type": "object"
+      },
+      "amount": {
+        "type": "number"
+      },
+      "currency": {
+        "type": "string"
+      },
+      "date": {
+        "type": "string"
+      },
+      "judgeModelId": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "sourceDocument": {
+        "additionalProperties": false,
+        "properties": {
+          "contentHash": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          }
+        },
+        "required": [
+          "contentHash"
+        ],
+        "type": "object"
+      },
+      "transactionId": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "date",
+      "amount",
+      "currency",
+      "account",
+      "sourceDocument",
+      "transactionId",
+      "judgeModelId"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

changedOutput schema / required

Previous value: -[
-  "dateRange",
-  "destinations",
-  "mayBeOwnAccount",
-  "scope"
-]New value: +[
+  "dateRange",
+  "destinations",
+  "mayBeOwnAccount",
+  "unresolved",
+  "scope"
+]

AddedOct 6, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only cover safety (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the description carries real burden and delivers: it discloses what is excluded (internal transfers, fees), how destinations cluster into five kinds, that amounts are cumulative per currency 'never a balance', and special non-totaled buckets (mayBeOwnAccount, unresolved) that are kept visible and never merged. This is behaviorally rich 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.

Conciseness3/5

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

All content is relevant, but it is delivered as a single dense run-on paragraph with deeply nested parentheticals and quote marks, making the destination-kind enumeration hard to scan. It is not padded, but front-loading and structural separation are weak.

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?

An output schema exists so return values needn't be explained, and the description still adds the key output trait (cumulative per-currency amount, not a balance, with separate non-totaled buckets). Combined with the scoping and matching caveats, an agent has everything needed to call it correctly.

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 baseline is 3. The description adds genuine semantics: dateRange is inclusive YYYY-MM-DD and usable 'from a separation date', and crucially that transfers are matched over the whole scope first so an out-of-range credit still counts as a transfer; it also advises preferring dateRange over a scope date range. That is meaning beyond the schema text.

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?

It states a precise verb+resource with explicit scope exclusions: 'Every debit that left your accounts — in no confirmed transfer between your own accounts, and not a fee'. It also differentiates from sibling list_transactions by explicitly forbidding summation of its rows. An agent can identify the resource and its boundaries without opening the schema.

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 gives a strong when-to-use ("THE way to answer 'did money disappear from my accounts, and where do I look next'") and an explicit anti-pattern ("never answer it by summing list_transactions rows"). However, it does not lay out the alternative siblings for adjacent jobs (e.g. list_transfers, adjudicate_outflows/adjudicate_transfers), so the routing map is incomplete.

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.