Skip to main content
Glama
bankstatemently

bankstatemently

Official
by bankstatemently
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Remote

Top Transaction Groups

top_n
Read-only

Rank groups by a chosen metric (sum, average, count, max, min) to return the top N, with per-currency results and optional scope for bank statement analysis.

Instructions

Return the top N groups ranked by metric (descending), per-currency for monetary metrics. Scope defaults to all your completed statements; pass "scope" to narrow to specific accounts/products and/or a date range.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nYesNumber of top groups to return.
scopeNoOptional 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).
filterNoSubset of transactions to operate on. All fields are optional and combined with AND logic.
metricYesMetric to rank by.
dimensionYesGrouping dimension.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv2.0.0
    • addedInput schema / properties / filter / additionalProperties
      Added value: +false
    • removedInput schema / properties / filter / properties / accounts
      Removed value: -{
-  "description": "Account number slugs to include.",
-  "items": {
-    "type": "string"
-  },
-  "type": "array"
-}
    • changedInput schema / properties / scope / description
      Previous 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)."New value: +"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)."
    • changedInput schema / properties / scope / properties / accounts / description
      Previous value: -"Account/product chips (kind + identityKey) to scope to. Empty = all accounts."New value: +"Account/product id chips (kind + id) to scope to. Empty = all accounts."
    • changedInput schema / properties / scope / properties / accounts / items / oneOf
      Previous 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"
-  }
-]New value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "id": {
+        "description": "The account id: the `id` of an account descriptor returned by a tool, or of a statement tool `accounts[]` entry.",
+        "format": "uuid",
+        "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+        "type": "string"
+      },
+      "kind": {
+        "const": "account",
+        "description": "This chip addresses a single account.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "kind",
+      "id"
+    ],
+    "type": "object"
+  },
+  {
+    "additionalProperties": false,
+    "properties": {
+      "id": {
+        "description": "The product id: the `id` of a product returned by a statement tool (`get_statement` / `convert_statement`, `products[].id`).",
+        "format": "uuid",
+        "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+        "type": "string"
+      },
+      "kind": {
+        "const": "product",
+        "description": "This chip addresses a product and expands to its child accounts.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "kind",
+      "id"
+    ],
+    "type": "object"
+  }
+]
  2. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds genuinely new behavior: default ordering is descending, monetary metrics are reported per-currency, and scope defaults to all completed statements unless narrowed.

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?

Two sentences, front-loaded with the core behavior, and every clause carries information. Slightly compressed phrasing like 'per-currency for monetary metrics' costs a little immediacy but no real waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter tool with a deeply nested scope/filter schema and no output schema, the description covers scoping and defaults but says nothing about what is returned (e.g. the shape of each ranked group). An agent knows how to call it, but not fully what to expect back.

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 still adds meaning beyond the schema by disclosing the descending sort order for the ranking, the per-currency split for monetary metrics, and the default scope behavior for the optional 'scope' parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb+resource: 'Return the top N groups ranked by metric (descending)'. This clearly separates it from the coarser analytical siblings like group_by and aggregate, though it never names those siblings explicitly to route the agent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the default scope behavior and that 'scope' narrows results, which is useful context. However, there is no explicit guidance on when to choose top_n over group_by, aggregate, or compare, so the when-to-use decision is left to inference.

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