Bankstatemently

Request Upload URL

request_upload

Mint a single-use upload URL for pushing a conversation-attached PDF to Bankstatemently before converting it. Use this ONLY when you have no other way to reference the attached file (no pdf_file/pdf_url equivalent for this host) — e.g. a code-execution sandbox that can see the file on disk but has no URL for it. Playbook: (1) check your sandbox's uploads/attachments directory first — if the file isn't there yet, the mount can lag behind the conversation; ask the user to re-attach or wait a moment and check again before calling this tool. (2) Call request_upload to get upload_url and upload_id. (3) PUT the raw PDF bytes to upload_url with header Content-Type: application/pdf, e.g.: curl -X PUT "<upload_url>" -H "Content-Type: application/pdf" --data-binary @<path-to-file>. (4) Once the PUT succeeds, call convert_statement with upload_id set to the same value — never pdf/pdf_url/pdf_file for this flow. The URL and token are single-use and expire quickly; call request_upload again for a fresh one if the PUT fails partway through — never retry a failed PUT against the same URL. If the PUT fails with a network error or a "host not allowed"-style denial, the sandbox is likely blocking outbound requests to api.bankstatemently.com — tell the user to add api.bankstatemently.com to their host's code-execution allowed-domains setting (on claude.ai: Settings → Capabilities → Code execution) and retry. To convert several statements at once, pass count (1-100) instead of calling this tool once per file: the response returns "uploads", an array of that many { upload_id, upload_url } pairs — PUT each file to its own upload_url, then make ONE convert_statement call with upload_ids set to every upload_id. Free to use — no credits consumed (conversion itself still costs credits, same as any other convert_statement call).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`count`	No	Batch size — mint this many independent single-use upload URLs in one call instead of calling request_upload once per file. When set, the response returns "uploads": an array of that many { upload_id, upload_url } pairs. Omit for the default single-URL response.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`uploads`	No
`max_bytes`	No
`upload_id`	No
`expires_at`	No
`upload_url`	No

Schema Changelog

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

Changed3 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 / count / description

Added value: +"Batch size — mint this many independent single-use upload URLs in one call instead of calling request_upload once per file. When set, the response returns \"uploads\": an array of that many { upload_id, upload_url } pairs. Omit for the default single-URL response."

changedOutput schema / $schema

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

Changed1 schema field changedAug 21, 2026

removedInput schema / properties / count / description

Removed value: -"Batch size — mint this many independent single-use upload URLs in one call instead of calling request_upload once per file. When set, the response returns \"uploads\": an array of that many { upload_id, upload_url } pairs. Omit for the default single-URL response."

Changed3 schema fields changedAug 17, 2026

addedInput schema / properties / count

Added value: +{
+  "description": "Batch size — mint this many independent single-use upload URLs in one call instead of calling request_upload once per file. When set, the response returns \"uploads\": an array of that many { upload_id, upload_url } pairs. Omit for the default single-URL response.",
+  "maximum": 100,
+  "minimum": 1,
+  "type": "integer"
+}

addedOutput schema / properties / uploads

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "upload_id": {
+        "type": "string"
+      },
+      "upload_url": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "upload_id",
+      "upload_url"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

removedOutput schema / required

Removed value: -[
-  "upload_id",
-  "upload_url",
-  "expires_at",
-  "max_bytes"
-]

First observedAug 12, 2026

TDQS

A5/5.0

Behavior5/5

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

The description discloses key behavioral traits beyond annotations: the URL and token are single-use and expire quickly, PUT failures may indicate outbound blocking, and the tool is free (no credits consumed). It also explains the batch response shape ('uploads' array). The annotations do not contradict this — readOnlyHint=false is consistent with minting a URL, and destructiveHint=false is consistent with a non-destructive operation.

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 and operationally precise, front-loading the core purpose and then moving through a numbered playbook, failure handling, and batching. Despite its length, every sentence carries actionable information — no filler or repetition of structured data.

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?

The description covers prerequisites (check sandbox directory), the full call sequence, error handling (network denials, allowed-domains settings), batching, credit implications, and the relationship to convert_statement. It assumes the output schema exists and does not waste space explaining return values. Nothing an agent needs to invoke this tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even though schema coverage is 100% for the single count parameter, the description adds significant workflow meaning: count is not just a batch size but a way to get an array of upload pairs, and it changes the downstream convert_statement call (upload_ids instead of upload_id). The description explains the exact PUT step and curl example, going well beyond the schema's brief description.

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 ('Mint') and resource ('single-use upload URL'), and immediately connects it to the larger workflow: pushing a conversation-attached PDF to Bankstatemently before conversion. It is distinguishable from sibling tools because it names convert_statement as the downstream consumer and explains its unique role in the upload flow.

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 states explicitly when to use this tool ('ONLY when you have no other way to reference the attached file') and gives a concrete example (code-execution sandbox). It also provides a playbook with pre-checks, alternative actions (ask user to re-attach), batch usage ('pass count instead of calling this tool once per file'), and exclusions ('never retry a failed PUT against the same URL').

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.

Request Upload URL

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

TDQS

Resources