Bankstatemently

Name: Bankstatemently
Author: bankstatemently

by io.github.bankstatemently

Server Details

Convert PDF bank statements into structured transactions, accounts, and balances.

Ownership verified

Status: Healthy
Last Tested: 2026-09-06 07:38
Transport: Streamable HTTP
URL
Repository: bankstatemently/plugins
GitHub Stars: 1
Server Listing: bankstatemently

Available Tools

16 tools

aggregateAggregate TransactionsA

Read-only

Inspect

Compute a single metric (sum/average/count/max/min) over a filtered set of transactions across your converted statements. Results are per-currency — never sum across currencies yourself. Scope defaults to all your completed statements; pass "scope" to narrow to specific accounts/products and/or a date range. For "how many credits do I have" / processing quota / remaining pages, use get_credits instead — that is not a transaction.

ParametersJSON Schema

Name	Required	Description
`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).
`filter`	No	Subset of transactions to operate on. All fields are optional and combined with AND logic.
`metric`	Yes	Aggregation metric.

Output Schema

ParametersJSON Schema

Name	Required	Description
`scope`	Yes
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare the operation read-only and non-destructive, so the bar for behavioral disclosure is lower. The description adds valuable behavioral context beyond annotations: results are per-currency and must not be summed across currencies, and the scope defaults to all completed statements. This is meaningful operational guidance that the annotations alone do not convey.

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 three sentences, front-loads the core action, and avoids redundancy. Each sentence earns its place: the operation, the critical per-currency caveat, the scope default, and the sibling-tool routing. There is zero filler.

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

Completeness4/5

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

With an output schema present, return-value explanation is unnecessary, and the input schema is rich. The description supplies the key contextual pieces: default scope, scope narrowing options, and the get_credits exclusion. It could go slightly further by clarifying how scope and filter relate to each other, but overall the agent has enough to call this tool correctly.

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

Parameters3/5

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

Schema coverage is 100%, so the input schema already documents all parameters thoroughly. The description restates the metric options and scope intent, but adds little that is not already in the schema. The 'never sum across currencies' caveat is useful but is not a parameter-level semantic addition.

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 opens with a precise verb-object statement: 'Compute a single metric (sum/average/count/max/min) over a filtered set of transactions...' This clearly identifies the tool's action and resource, and differentiates it from sibling tools like get_credits by explicitly stating what it is not. The title and name are generic, but the description fully disambiguates them.

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?

The description gives explicit default behavior and clearly routes non-transaction queries such as credits/quota to get_credits instead. However, it does not address sibling aggregation-related tools like group_by, time_series, or top_n, so an agent has less guidance on choosing among those alternatives. Still, the provided context and exclusion are useful and specific.

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

categorize_statementCategorize TransactionsAInspect

Run AI transaction categorization on a previously processed document, then return its category mappings. Returns cached categories with no charge if this document was already categorized. Consumes credits (pooled per page, same rate as the categorize toggle on the website) the first time — free on every re-fetch after. Every response includes a "summary" field: use it as the single source of truth for what happened.

ParametersJSON Schema

Name	Required	Description	Default
`document_id`	Yes	Document ID (from convert_statement or list_statements)

Output Schema

ParametersJSON Schema

Name	Required	Description
`hint`	No
`error`	No
`status`	Yes
`message`	No
`summary`	No
`documentId`	No
`categoryMappings`	No

TDQS

A4.4/5.0

Behavior5/5

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

The description discloses credit consumption, page-pooled pricing, caching behavior, and the always-present summary field. This goes well beyond the sparse annotations and aligns with readOnlyHint=false, since categorization incurs credits on first use.

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?

The description is front-loaded with the primary action and then adds cost/caching and response guidance. There is slight redundancy between 'Returns cached categories with no charge' and 'free on every re-fetch after,' but the paragraph is compact and focused.

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 single-parameter tool with an output schema and annotations, the description covers prerequisites, cost behavior, caching, and response interpretation ('summary' field). An agent has enough information to call it correctly without external context.

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

Parameters3/5

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

There is only one parameter and the input schema already describes document_id with 100% coverage, including its source. The description's 'previously processed' reinforces the prerequisite without adding significant new semantic detail.

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 names a specific verb and resource ('Run AI transaction categorization on a previously processed document') and states the deliverable ('return its category mappings'). It clearly distinguishes this tool from listing, conversion, and comparison siblings by focusing on categorization of an already-processed document.

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?

The phrase 'previously processed document' and the parameter description 'from convert_statement or list_statements' give clear prerequisite context for when to call it. It does not explicitly name alternatives or exclude cases like raw/unprocessed documents, but the intended usage is evident.

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

compareCompare Transaction GroupsA

Read-only

Inspect

Side-by-side metric comparison for two filtered groups of transactions (e.g. one category vs another, one month vs another). Scope defaults to all your completed statements; pass "scope" to narrow to specific accounts/products and/or a date range.

ParametersJSON Schema

Name	Required	Description
`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).
`metric`	Yes	Metric for both groups.
`filterA`	Yes	Subset of transactions to operate on. All fields are optional and combined with AND logic.
`filterB`	Yes	Subset of transactions to operate on. All fields are optional and combined with AND logic.

Output Schema

ParametersJSON Schema

Name	Required	Description
`scope`	Yes
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already establish readOnlyHint=true and destructiveHint=false, so no safety contradiction exists. The description adds useful behavioral context by explaining that the default scope is all completed statements and that the scope parameter can narrow by accounts/products and date range. This is meaningful beyond the structured 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 two concise sentences with the core purpose front-loaded. The examples are useful and the scoping note is directly actionable. Every sentence earns its place with no redundancy or fluff.

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

Completeness4/5

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

For a tool with nested parameters, an output schema, and multiple aggregation siblings, this definition covers the essential behavioral and scoping facts. It could be slightly stronger by explicitly stating when to choose compare over aggregate or group_by, but the description plus schema is sufficient for correct invocation.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all parameters in detail. The description mentions 'scope' and gives examples of filter groups, but it does not add meaningful parameter semantics beyond what the schema provides. Baseline 3 is appropriate.

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 states a specific action ('Side-by-side metric comparison') on a clear resource ('two filtered groups of transactions') and gives concrete examples ('one category vs another, one month vs another'). This distinguishes it from sibling tools like aggregate, group_by, and top_n by emphasizing pairwise comparison.

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?

The description clearly conveys when to use the tool: whenever two filtered transaction groups need comparison. It also provides scoping guidance ('Scope defaults to all your completed statements; pass "scope" to narrow...'). It does not explicitly name alternatives or exclusion conditions, but the use case is clear enough.

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

convert_statementConvert Bank StatementAInspect

Convert a bank statement PDF into structured data or a spreadsheet. When the user attaches a PDF in the conversation, it arrives automatically as pdf_file — never encode it yourself. Otherwise, pass pdf_url for a public HTTPS link. If your host has no way to reference the attached file at all (no pdf_file/pdf_url equivalent), call request_upload first and pass its upload_id here instead. The base64 pdf parameter is a last resort only, for a caller with no other way to reference the file. To convert several statements in one call, pass upload_ids (the array from a single request_upload call made with count set) instead of pdf/pdf_url/pdf_file/upload_id — mutually exclusive with those four. This batch form only ADMITS each file (queues it, or reports an already-completed duplicate) and returns immediately with a compact per-file status list plus a summary — it never waits for conversion, so call get_statement per document_id once ready rather than expecting inline results here. Returns accounts, transactions, and metadata. 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. 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. Consumes credits (1 per page). Page limit depends on your plan.

ParametersJSON Schema

Name	Required	Description	Default
`pdf`	No	Base64-encoded PDF content — last resort only; prefer pdf_file for an attachment or pdf_url for a link
`pdf_url`	No	HTTPS URL to fetch the PDF from
`password`	No	Password for encrypted PDFs
`pdf_file`	No	An attached PDF (populated automatically by ChatGPT — do not construct this yourself).
`upload_id`	No	An upload_id from request_upload, after PUTting the file to its upload_url. Use this only when your host has no other way to reference the attached file (no pdf_file/pdf_url equivalent).
`upload_ids`	No	Batch of upload_ids from a single request_upload(count) call, each already PUT to its own upload_url — converts many statements in one call. Mutually exclusive with pdf, pdf_url, pdf_file, and upload_id. Admission only: the response reports per-file status immediately, never waiting for conversion — fetch results per document_id via get_statement.
`output_format`	No	Output format	json

Output Schema

ParametersJSON Schema

Name	Required	Description
`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

TDQS

A5/5.0

Behavior5/5

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

Beyond the annotations, the description discloses key behaviors: batch mode only admits/queues files and returns immediately rather than waiting, non-JSON outputs return time-limited download links, every response includes a summary field to use as the source of truth, credits are consumed per page, and the description instructs faithful translation of the summary. These are important non-obvious behaviors that an agent needs to know.

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 long but every sentence serves a purpose. It front-loads the core conversion purpose and then covers attached-file handling, batch behavior, output formats, summary guidance, and credit consumption without redundancy. The density is justified by the tool's complexity.

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 the rich schema, output schema, and sibling context, the description covers everything an agent needs to call this tool correctly: file source selection, batch vs single conversion, result retrieval via get_statement, output format behavior, summary handling, and credit cost. No critical operational gap is left unaddressed.

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?

Although the schema covers 100% of parameters, the description adds meaning beyond the schema: pdf_file is populated automatically and should never be constructed manually; base64 is a last resort; upload_ids are mutually exclusive with all other file-reference parameters; and output_format json returns inline data while other formats return download links. This substantially clarifies parameter selection.

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 opens with a specific verb and resource: 'Convert a bank statement PDF into structured data or a spreadsheet.' This immediately distinguishes the tool from sibling tools like list_statements, get_statement, and categorize_statement, and it clearly identifies the conversion behavior.

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 and when-not-to-use guidance: use pdf_file for attachments, pdf_url for public links, upload_id when no attachment reference exists, base64 only as a last resort, and upload_ids for batch conversion while pointing to get_statement for fetching results. It also states which parameters are mutually exclusive.

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

dismiss_statementDismiss StatementAInspect

Hide a failed, rejected, or cancelled document from future list_statements results. Use this only when the user asks to clear a terminal failed/rejected/cancelled conversion from their history. This is not a delete: it marks the document dismissed and leaves stored data/artifacts untouched.

ParametersJSON Schema

Name	Required	Description	Default
`document_id`	Yes	Document ID from list_statements, convert_statement, or get_statement

Output Schema

ParametersJSON Schema

Name	Required	Description
`status`	Yes
`summary`	Yes
`documentId`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already indicate this is not read-only and not destructive. The description adds important context beyond that: it marks the document dismissed, hides it from future results, and leaves stored data/artifacts untouched. This clarifies the mutation semantics without contradicting 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?

Two focused sentences cover the action, the appropriate usage context, and the key non-destructive distinction. There is no filler, and the most important scoping information is front-loaded.

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 one-parameter tool with an output schema and clear annotations, the description covers what the tool does, when to use it, what it does not do, and the persistence of the underlying data. Nothing necessary for correct invocation is missing.

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

Parameters3/5

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

Schema description coverage is 100%, and the document_id parameter already explains where to obtain the ID. The description does not add additional parameter-level detail, which is acceptable because the schema fully documents the only parameter.

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 ('Hide') with a clearly scoped resource: failed, rejected, or cancelled documents excluded from future list_statements results. It also explicitly distinguishes itself from deletion, which differentiates it from sibling tools that might otherwise seem related.

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?

The description gives an explicit when-to-use condition: 'Use this only when the user asks to clear a terminal failed/rejected/cancelled conversion from their history.' It also warns that this is not a delete, but it does not name an alternative tool for actual deletion, so the guidance is strong but not fully complete.

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

evaluate_benchmarkEvaluate BenchmarkA

Read-only

Inspect

Score parsed bank statement transactions against the Bankstatemently benchmark ground truth. Accepts a statement_id (e.g. "bsb-001") or content_hash, plus your parsed transactions. Returns extraction accuracy, integrity score, and an overall score. Only statements marked published: true in the catalog can be evaluated — held-out statements return an error. transactions[].originalData is optional but strongly recommended: fetch it via get_statement with data_mode: "original" and pass it through verbatim — an absent originalData scores that transaction's raw-fidelity (parsed) dimension 0; never fabricate a value. Free to use — no credits consumed. Read the benchmark://catalog resource first to see available statements and their published status.

ParametersJSON Schema

Name	Required	Description
`accounts`	No	Optional account roster for multi-account statements. Each transaction references one via accountId.
`content_hash`	No	SHA-256 hex digest of the PDF. Use statement_id instead if you know it.
`statement_id`	No	Benchmark statement ID (e.g. "bsb-001"). Preferred over content_hash.
`transactions`	Yes	Parsed transactions (1-2000)

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`challenges`	Yes
`difficulty`	Yes
`parsedScore`	Yes
`normalizedScore`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the readOnly/destructive annotations, it discloses that absent originalData zero-scores the raw-fidelity dimension, warns against fabricating values, notes the published-only restriction, and states that no credits are consumed. This is significant operational behavior an agent needs to know.

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, identifier preference, originalData guidance, scoring consequence, pricing, and prerequisite resource. It is front-loaded with the action and then adds necessary operational context without padding.

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 benchmark evaluation tool, it covers inputs, output metrics, prerequisites, error case, optional-data handling, and credit cost. With an output schema present, no return-shape detail is missing. An agent has everything needed to call this correctly.

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%, the description adds decision-critical semantics: statement_id is preferred over content_hash, originalData is strongly recommended and should be passed through verbatim from get_statement, and omission has scoring consequences. This goes well beyond the schema field names.

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 opens with a specific verb ('Score') and resource ('parsed bank statement transactions against the Bankstatemently benchmark ground truth'), and names the concrete output metrics (extraction accuracy, integrity score, overall score). This clearly separates it from sibling tools like list_statements or rate_statement.

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 explicit preconditions — only published:true statements can be evaluated, held-out statements return an error — and directs the agent to read the benchmark://catalog resource first. It also recommends fetching originalData via get_statement with data_mode 'original', but does not explicitly enumerate when to choose this over sibling scoring/evaluation tools.

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

get_creditsGet Credit Balance (processing quota)A

Read-only

Inspect

Your remaining Bankstatemently credits — the processing quota, NOT credit/debit transactions. Use for: how many credits do I have, remaining pages, plan limits, quota, how many pages can I upload. 1 credit = 1 page of bank statement processing. Also reports your plan's operational limits (max pages per upload, max upload size, daily spend cap) so you can size a multi-file batch correctly before starting it.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`plan`	Yes
`limit`	Yes
`planId`	Yes
`balance`	Yes
`summary`	Yes
`creditsExpireAt`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by disclosing that the tool also reports operational limits like max pages per upload and daily spend cap, which goes beyond a simple balance read.

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?

The description is slightly long but front-loaded with the core message and then organized into use cases, a definition, and additional output details. Every sentence contributes useful information, though some redundancy exists between 'remaining pages', 'quota', and 'processing quota'.

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 zero-parameter read-only tool with an output schema and annotations, the description fully covers what the tool does, what it reports, and when to use it. Nothing critical is missing for an agent to select and invoke this tool 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?

The tool has zero parameters, so the schema imposes no burden on the description. The description adds meaningful semantic detail by explaining what 'credits' means in terms of pages, which helps the agent interpret the output even without parameters.

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 explicitly identifies the resource as remaining Bankstatemently credits / processing quota and distinguishes it from credit/debit transactions. The mapping '1 credit = 1 page' makes the tool's purpose concrete and unambiguous.

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?

The description provides explicit use cases ('how many credits do I have, remaining pages, plan limits, quota') and a clear exclusion ('NOT credit/debit transactions'). It stops short of naming an alternative sibling tool, but the use-case guidance is strong enough for an agent to know when to invoke this tool.

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

get_statementGet Statement DataA

Read-only

Inspect

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.

ParametersJSON 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

ParametersJSON Schema

Name	Required	Description
`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

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.

group_byGroup TransactionsA

Read-only

Inspect

Group transactions by a dimension (month/category/merchant/account/currency) and apply a metric to each group. Results are per-currency. Scope defaults to all your completed statements; pass "scope" to narrow to specific accounts/products and/or a date range.

ParametersJSON Schema

Name	Required	Description
`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).
`filter`	No	Subset of transactions to operate on. All fields are optional and combined with AND logic.
`metric`	Yes	Metric per group.
`dimension`	Yes	Grouping dimension.

Output Schema

ParametersJSON Schema

Name	Required	Description
`scope`	Yes
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context beyond those annotations: grouping semantics, per-currency results, and default scoping behavior. No contradiction with annotations is present.

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 three short sentences with no filler. The core action is front-loaded, the dimension list is compact, and the scope default/narrowing behavior earns its place.

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

Completeness4/5

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

Given the tool's nested scope and filter parameters, the description covers the central operation, default scope, and result shape, while the schema covers detailed parameter semantics and an output schema exists. It is slightly incomplete only in not mentioning the filter parameter or sibling alternatives.

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

Parameters3/5

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

Schema description coverage is 100% and the JSON Schema parameter descriptions are already detailed. The description adds a helpful steering note about the 'scope' parameter, but does not materially explain dimension, metric, or filter semantics beyond what the schema provides.

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 specific operative language: 'Group transactions by a dimension... and apply a metric to each group,' lists the exact dimensions, and notes per-currency output. This clearly distinguishes it from general listing tools like list_transactions and from pure time-series tools like time_series.

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 clear usage context: results are per-currency, scope defaults to all completed statements, and passing 'scope' narrows by accounts/products or date range. It does not explicitly contrast with siblings like aggregate or top_n, so exclusion guidance is absent.

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

list_statementsList StatementsA

Read-only

Inspect

Browse your previously converted bank statements with pagination and optional status filter.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max results (1-100)
`offset`	No	Pagination offset
`status`	No	Filter by status

Output Schema

ParametersJSON Schema

Name	Required	Description
`documents`	Yes
`pagination`	Yes

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, which match the 'Browse' behavior in the description. The description adds the useful scope that only previously converted statements are included, but does not disclose further behavioral details like ordering or auth requirements.

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?

A single, front-loaded sentence that conveys the verb, resource, scope, pagination, and optional filter with no unnecessary words. Every phrase earns its place.

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

Completeness4/5

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

Given the annotations, complete parameter schema, and existing output schema, the description provides the essential usage context. It is slightly less explicit about when not to use this tool compared with alternatives, but nothing critical is missing for a read-only listing operation.

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

Parameters3/5

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

Schema description coverage is 100%, so the parameters limit, offset, and status are fully documented in the schema. The description mentions pagination and an optional status filter, which aligns with the schema but adds no new parameter-level meaning.

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 clearly identifies the action ('Browse'), the resource ('previously converted bank statements'), and the key options (pagination, status filter). It is distinct from sibling list tools like list_transactions and list_transfers because it is explicitly scoped to converted bank statements.

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?

The description gives clear context: use this tool to browse previously converted bank statements, optionally filtered by status. It does not explicitly name alternatives or exclusions, but the resource scoping is enough to distinguish it from related list/get tools.

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

list_transactionsList TransactionsA

Read-only

Inspect

A transaction is a single line as printed on one account's statement — one side of any movement. Return a filtered list of transactions across your converted statements, capped at 50 rows. Scope defaults to all your completed statements; pass "scope" to narrow to specific accounts/products and/or a date range. Every response names the scope it actually evaluated (document count + covered date range) and each returned row carries its source document's content_hash so you can cite it. For "how many credits do I have" / processing quota / remaining pages, use get_credits instead — that is not a transaction.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum rows to return. Default 20, max 50.
`order`	No	Sort direction. Default "desc" (largest amount / most recent date first). Only meaningful with sort_by.
`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).
`filter`	No	Subset of transactions to operate on. All fields are optional and combined with AND logic.
`sort_by`	No	Sort the filtered set before applying limit. "amount" ranks by absolute magnitude (signed amounts are still returned). Omit for today's default (encounter order).

Output Schema

ParametersJSON Schema

Name	Required	Description
`scope`	Yes
`transactions`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the read-only annotations, the description discloses meaningful behaviors: every response names the evaluated scope (document count + date range), each row carries a content_hash for citation, and the default sorting and 50-row cap are stated. This goes well beyond annotation hints.

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 a single, well-organized paragraph that front-loads the core purpose and cap, then clarifies scope behavior, response guarantees, and a routing note for an alternative tool. Every sentence adds value with no redundancy or fluff.

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 the complexity (5 parameters, nested objects, enums) and the existing output schema, the description is complete: it covers the tool's purpose, default scope, response details (content_hash, scope feedback), and the credit caveat. The filter parameter is documented in the schema, so its omission from the description is acceptable.

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?

The schema covers 100% of parameter descriptions, so the baseline is 3. The description adds value by explaining defaults (scope defaults to all statements, sort_by default is encounter order, limit cap of 50) and giving high-level context about the 'scope' parameter, though it doesn't elaborate on the 'filter' object—still, the extra default context earns a 4.

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 clearly states that the tool returns a filtered list of transactions across converted statements, capped at 50 rows, and defines what a transaction is (one side of any movement). It explicitly distinguishes from get_credits, and the scope default is explained, making the tool's purpose unambiguous even among siblings like list_transfers.

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?

Provides explicit when-not guidance: 'For how many credits do I have / processing quota / remaining pages, use get_credits instead.' It also explains how to narrow the default scope via the 'scope' parameter, which gives clear direction on when to use alternatives and how to adjust usage.

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

list_transfersMatch Transfers Between AccountsA

Read-only

Inspect

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.

ParametersJSON 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

ParametersJSON Schema

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

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.

rate_statementRate Statement ConversionAInspect

Report how well a previously converted bank statement was parsed: submit a 1-5 rating, optionally with structured feedback (only accepted when the rating is 3 or below) and use-case tags. Calling this again for the same document updates your existing rating and clears any previous feedback tied to it. Returns the stored rating state in the response — there is no separate tool to read your own rating back. Every response includes a "summary" field: use it as the single source of truth for what happened.

ParametersJSON Schema

Name	Required	Description
`rating`	Yes	1-5 star rating for this conversion
`feedback`	No	Free-text feedback. Only accepted when rating is 3 or below.
`use_case`	No	Tags describing what you use the converted data for.
`document_id`	Yes	Document ID (from convert_statement or list_statements)
`export_format`	No	Which output format you exported this conversion to (csv, xlsx, qbo, or xero).
`use_case_other`	No	Free-text use case, for when "other" is among the use_case tags.
`feedback_categories`	No	Structured feedback categories. Only accepted when rating is 3 or below.

Output Schema

ParametersJSON Schema

Name	Required	Description
`hint`	No
`error`	No
`rating`	No
`status`	Yes
`message`	No
`summary`	No
`useCase`	No
`documentId`	No
`hasFeedback`	No
`useCaseOther`	No

TDQS

A3.8/5.0

Behavior1/5

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

The description is transparent about calling again updating the existing rating and clearing previous feedback, and mentions the response summary. However, this directly contradicts the annotation destructiveHint=false, because clearing previous feedback is a destructive side effect. The description and annotations are inconsistent, which is a serious reliability issue.

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?

The description is information-dense and front-loaded with the core purpose. The sentences about returning stored rating state and including a summary field are slightly redundant, but the overall structure is still tight and every sentence adds operational value.

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 the 7-parameter schema, 100% parameter coverage, and presence of an output schema, the description is complete. It explains the core action, update/overwrite behavior, feedback acceptance conditions, and response interpretation without needing to enumerate return fields.

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 meaningful constraints beyond the schema by clarifying that structured feedback is only accepted when the rating is 3 or below, and by framing the optional tags. Not every parameter is discussed, but the schema already documents each one well.

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 states a specific action and resource: 'Report how well a previously converted bank statement was parsed' and 'submit a 1-5 rating'. This clearly distinguishes the tool from conversion and listing siblings such as convert_statement and list_statements.

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 clear context that the tool is for rating an already-converted statement, and explains the update semantics for repeated calls. It does not explicitly name alternatives or say when not to use it, but the context is strong enough for an agent to select it appropriately.

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

request_uploadRequest Upload URLAInspect

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).

ParametersJSON 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

ParametersJSON Schema

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

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.

time_seriesTransaction Time SeriesA

Read-only

Inspect

Compute a time series by grouping transactions into week or month buckets and applying a metric — useful for trends. Scope defaults to all your completed statements; pass "scope" to narrow to specific accounts/products and/or a date range.

ParametersJSON Schema

Name	Required	Description
`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).
`bucket`	Yes	Bucket size.
`filter`	No	Subset of transactions to operate on. All fields are optional and combined with AND logic.
`metric`	Yes	Metric per bucket.

Output Schema

ParametersJSON Schema

Name	Required	Description
`scope`	Yes
`result`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already establish read-only and non-destructive behavior, so the description adds value by disclosing behavioral defaults: it operates on all completed statements by default and can be narrowed via 'scope'. This provides meaningful context beyond the annotations, though it could say more about how filter interacts with scope.

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 two sentences with no filler. It front-loads the primary purpose and then states the default scope and a key parameter. Every sentence earns its place.

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

Completeness4/5

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

Given the rich input schema and existing output schema, the description is largely sufficient: it communicates the main computation, the default scope, and the optional narrowing mechanism. It does not explicitly clarify the relationship between the 'scope' and 'filter' objects, which is a minor gap in an otherwise complete definition.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds a plain-language summary of the 'scope' parameter ('narrow to specific accounts/products and/or a date range') but does not substantially enrich understanding of 'bucket' or 'metric' beyond what the schema provides. This aligns with the baseline of 3.

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 clearly identifies a specific verb ('Compute'), resource ('time series'), and the core mechanism ('grouping transactions into week or month buckets and applying a metric'). It effectively conveys what the tool does, though it does not explicitly distinguish it from siblings like group_by or aggregate.

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?

The description gives an implied usage context ('useful for trends') and explains the default scope ('all your completed statements'), which helps an agent understand when it might be relevant. However, it does not state when to prefer this tool over alternatives such as group_by or aggregate, nor does it outline exclusions.

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

top_nTop N TransactionsA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`n`	Yes	Number of top groups to return.
`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).
`filter`	No	Subset of transactions to operate on. All fields are optional and combined with AND logic.
`metric`	Yes	Metric to rank by.
`dimension`	Yes	Grouping dimension.

Output Schema

ParametersJSON Schema

Name	Required	Description
`scope`	Yes
`result`	Yes

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, lowering the bar. The description adds meaningful behavioral detail beyond annotations: results are per-currency for monetary metrics and the default scope is limited to completed statements. This helps the agent understand non-obvious runtime behavior.

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?

Two sentences with no filler: the first front-loads the core behavior and the second clarifies scope defaults and overrides. Every sentence earns its place.

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

Completeness4/5

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

Given a rich input schema, annotations, and an output schema, the description is nearly complete. It adds the essential default-scope and per-currency caveats not in the schema. A minor ambiguity about which metrics count as 'monetary' is a small gap, but not enough to hinder correct invocation.

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

Parameters3/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 mentions 'scope' as a narrowing mechanism but does not detail individual parameters; the schema already explains each. No contradiction, but the description adds little beyond what the schema provides.

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 states a specific verb ('Return'), a clear resource ('top N groups ranked by metric descending'), and adds a distinguishing per-currency behavior for monetary metrics. It stops short of explicitly differentiating from sibling aggregation tools like group_by or aggregate, so it is clear but not fully differentiated.

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?

The description gives explicit context on the default scope ('all your completed statements') and instructs how to narrow it using the 'scope' parameter. It does not mention when to prefer alternatives like aggregate or group_by, so there are no exclusions, but the usage context is clear.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

16 tool updatesSep 4, 2026

Changedaggregate21 fields changed

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 / filter / description

Added value: +"Subset of transactions to operate on. All fields are optional and combined with AND logic."

addedInput schema / properties / filter / properties / accounts / description
```
Added value: +"Account number slugs to include."
```
addedInput schema / properties / filter / properties / amountMax / description
```
Added value: +"Inclusive maximum absolute amount."
```
addedInput schema / properties / filter / properties / amountMin / description
```
Added value: +"Inclusive minimum absolute amount."
```

addedInput schema / properties / filter / properties / category / description

Added value: +"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"."

addedInput schema / properties / filter / properties / currency / description
```
Added value: +"ISO 4217 currency code. E.g. \"USD\", \"HKD\"."
```
addedInput schema / properties / filter / properties / dateEnd / description
```
Added value: +"ISO date (YYYY-MM-DD). Inclusive upper bound."
```
addedInput schema / properties / filter / properties / dateStart / description
```
Added value: +"ISO date (YYYY-MM-DD). Inclusive lower bound."
```
addedInput schema / properties / filter / properties / direction / description
```
Added value: +"Semantic direction."
```

addedInput schema / properties / filter / properties / merchant / description

Added value: +"Substring match against description or counterparty (case-insensitive)."

addedInput schema / properties / filter / properties / text / description

Added value: +"Whole-row text search over raw transaction fields (case-insensitive)."

addedInput schema / properties / metric / description
```
Added value: +"Aggregation metric."
```

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"

Changedcategorize_statement3 fields changed

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 / document_id / description

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

changedOutput schema / $schema

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

Changedcompare32 fields changed

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 / filterA / description

Added value: +"Subset of transactions to operate on. All fields are optional and combined with AND logic."

addedInput schema / properties / filterA / properties / accounts / description
```
Added value: +"Account number slugs to include."
```
addedInput schema / properties / filterA / properties / amountMax / description
```
Added value: +"Inclusive maximum absolute amount."
```
addedInput schema / properties / filterA / properties / amountMin / description
```
Added value: +"Inclusive minimum absolute amount."
```

addedInput schema / properties / filterA / properties / category / description

Added value: +"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"."

addedInput schema / properties / filterA / properties / currency / description
```
Added value: +"ISO 4217 currency code. E.g. \"USD\", \"HKD\"."
```
addedInput schema / properties / filterA / properties / dateEnd / description
```
Added value: +"ISO date (YYYY-MM-DD). Inclusive upper bound."
```
addedInput schema / properties / filterA / properties / dateStart / description
```
Added value: +"ISO date (YYYY-MM-DD). Inclusive lower bound."
```
addedInput schema / properties / filterA / properties / direction / description
```
Added value: +"Semantic direction."
```

addedInput schema / properties / filterA / properties / merchant / description

Added value: +"Substring match against description or counterparty (case-insensitive)."

addedInput schema / properties / filterA / properties / text / description

Added value: +"Whole-row text search over raw transaction fields (case-insensitive)."

addedInput schema / properties / filterB / description

Added value: +"Subset of transactions to operate on. All fields are optional and combined with AND logic."

addedInput schema / properties / filterB / properties / accounts / description
```
Added value: +"Account number slugs to include."
```
addedInput schema / properties / filterB / properties / amountMax / description
```
Added value: +"Inclusive maximum absolute amount."
```
addedInput schema / properties / filterB / properties / amountMin / description
```
Added value: +"Inclusive minimum absolute amount."
```

addedInput schema / properties / filterB / properties / category / description

Added value: +"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"."

addedInput schema / properties / filterB / properties / currency / description
```
Added value: +"ISO 4217 currency code. E.g. \"USD\", \"HKD\"."
```
addedInput schema / properties / filterB / properties / dateEnd / description
```
Added value: +"ISO date (YYYY-MM-DD). Inclusive upper bound."
```
addedInput schema / properties / filterB / properties / dateStart / description
```
Added value: +"ISO date (YYYY-MM-DD). Inclusive lower bound."
```
addedInput schema / properties / filterB / properties / direction / description
```
Added value: +"Semantic direction."
```

addedInput schema / properties / filterB / properties / merchant / description

Added value: +"Substring match against description or counterparty (case-insensitive)."

addedInput schema / properties / filterB / properties / text / description

Added value: +"Whole-row text search over raw transaction fields (case-insensitive)."

addedInput schema / properties / metric / description
```
Added value: +"Metric for both groups."
```

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"

Changedconvert_statement13 fields changed

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 / output_format / description
```
Added value: +"Output format"
```
addedInput schema / properties / password / description
```
Added value: +"Password for encrypted PDFs"
```

addedInput schema / properties / pdf / description

Added value: +"Base64-encoded PDF content — last resort only; prefer pdf_file for an attachment or pdf_url for a link"

addedInput schema / properties / pdf_file / description

Added value: +"An attached PDF (populated automatically by ChatGPT — do not construct this yourself)."

addedInput schema / properties / pdf_file / properties / download_url / description
```
Added value: +"Signed URL ChatGPT provides to fetch the attached PDF's bytes."
```
addedInput schema / properties / pdf_file / properties / file_id / description
```
Added value: +"ChatGPT's identifier for the attached file."
```

addedInput schema / properties / pdf_file / properties / file_name / description

Added value: +"Original filename of the attached file, when ChatGPT provides one."

addedInput schema / properties / pdf_file / properties / mime_type / description
```
Added value: +"MIME type of the attached file, when ChatGPT provides one."
```
addedInput schema / properties / pdf_url / description
```
Added value: +"HTTPS URL to fetch the PDF from"
```

addedInput schema / properties / upload_id / description

Added value: +"An upload_id from request_upload, after PUTting the file to its upload_url. Use this only when your host has no other way to reference the attached file (no pdf_file/pdf_url equivalent)."

addedInput schema / properties / upload_ids / description

Added value: +"Batch of upload_ids from a single request_upload(count) call, each already PUT to its own upload_url — converts many statements in one call. Mutually exclusive with pdf, pdf_url, pdf_file, and upload_id. Admission only: the response reports per-file status immediately, never waiting for conversion — fetch results per document_id via get_statement."

changedOutput schema / $schema

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

Changeddismiss_statement3 fields changed

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 / document_id / description

Added value: +"Document ID from list_statements, convert_statement, or get_statement"

changedOutput schema / $schema

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

Changedevaluate_benchmark18 fields changed

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 / accounts / description

Added value: +"Optional account roster for multi-account statements. Each transaction references one via accountId."

addedInput schema / properties / accounts / items / properties / accountNumber / description
```
Added value: +"Verbatim printed account number — never normalized by the submitter."
```
addedInput schema / properties / accounts / items / properties / currency / description
```
Added value: +"ISO 4217 currency code."
```

addedInput schema / properties / accounts / items / properties / id / description

Added value: +"Submission-internal handle, referenced by transactions[].accountId."

addedInput schema / properties / accounts / items / properties / name / description
```
Added value: +"Verbatim printed account label."
```

addedInput schema / properties / content_hash / description

Added value: +"SHA-256 hex digest of the PDF. Use statement_id instead if you know it."

addedInput schema / properties / statement_id / description

Added value: +"Benchmark statement ID (e.g. \"bsb-001\"). Preferred over content_hash."

addedInput schema / properties / transactions / description
```
Added value: +"Parsed transactions (1-2000)"
```

addedInput schema / properties / transactions / items / properties / accountId / description

Added value: +"References accounts[].id — the account this transaction belongs to. Omit for single-account statements."

addedInput schema / properties / transactions / items / properties / amount / description

Added value: +"Transaction amount. Negative = debit, positive = credit (or use direction)."

addedInput schema / properties / transactions / items / properties / balance / description
```
Added value: +"Running balance after this transaction, if known."
```
addedInput schema / properties / transactions / items / properties / currency / description
```
Added value: +"ISO 4217 currency code for this transaction, if known."
```
addedInput schema / properties / transactions / items / properties / date / description
```
Added value: +"ISO 8601 date (YYYY-MM-DD)"
```
addedInput schema / properties / transactions / items / properties / description / description
```
Added value: +"Transaction description as printed on the statement."
```
addedInput schema / properties / transactions / items / properties / direction / description
```
Added value: +"Explicit direction. If omitted, inferred from amount sign."
```

addedInput schema / properties / transactions / items / properties / originalData / description

Added value: +"Raw column values as on the PDF. Omit if unavailable — never fabricate a value; an absence scores the parsed dimension's raw fields 0 rather than polluting the measurement."

changedOutput schema / $schema

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

Changedget_credits2 fields changed

changedInput schema / $schema

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

changedOutput schema / $schema

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

Changedget_statement7 fields changed

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"

Changedgroup_by22 fields changed

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 / dimension / description
```
Added value: +"Grouping dimension."
```

addedInput schema / properties / filter / description

Added value: +"Subset of transactions to operate on. All fields are optional and combined with AND logic."

addedInput schema / properties / filter / properties / accounts / description
```
Added value: +"Account number slugs to include."
```
addedInput schema / properties / filter / properties / amountMax / description
```
Added value: +"Inclusive maximum absolute amount."
```
addedInput schema / properties / filter / properties / amountMin / description
```
Added value: +"Inclusive minimum absolute amount."
```

addedInput schema / properties / filter / properties / category / description

Added value: +"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"."

addedInput schema / properties / filter / properties / currency / description
```
Added value: +"ISO 4217 currency code. E.g. \"USD\", \"HKD\"."
```
addedInput schema / properties / filter / properties / dateEnd / description
```
Added value: +"ISO date (YYYY-MM-DD). Inclusive upper bound."
```
addedInput schema / properties / filter / properties / dateStart / description
```
Added value: +"ISO date (YYYY-MM-DD). Inclusive lower bound."
```
addedInput schema / properties / filter / properties / direction / description
```
Added value: +"Semantic direction."
```

addedInput schema / properties / filter / properties / merchant / description

Added value: +"Substring match against description or counterparty (case-insensitive)."

addedInput schema / properties / filter / properties / text / description

Added value: +"Whole-row text search over raw transaction fields (case-insensitive)."

addedInput schema / properties / metric / description
```
Added value: +"Metric per group."
```

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"

Changedlist_statements5 fields changed

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 / limit / description
```
Added value: +"Max results (1-100)"
```
addedInput schema / properties / offset / description
```
Added value: +"Pagination offset"
```
addedInput schema / properties / status / description
```
Added value: +"Filter by status"
```

changedOutput schema / $schema

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

Changedlist_transactions23 fields changed

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 / filter / description

Added value: +"Subset of transactions to operate on. All fields are optional and combined with AND logic."

addedInput schema / properties / filter / properties / accounts / description
```
Added value: +"Account number slugs to include."
```
addedInput schema / properties / filter / properties / amountMax / description
```
Added value: +"Inclusive maximum absolute amount."
```
addedInput schema / properties / filter / properties / amountMin / description
```
Added value: +"Inclusive minimum absolute amount."
```

addedInput schema / properties / filter / properties / category / description

Added value: +"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"."

addedInput schema / properties / filter / properties / currency / description
```
Added value: +"ISO 4217 currency code. E.g. \"USD\", \"HKD\"."
```
addedInput schema / properties / filter / properties / dateEnd / description
```
Added value: +"ISO date (YYYY-MM-DD). Inclusive upper bound."
```
addedInput schema / properties / filter / properties / dateStart / description
```
Added value: +"ISO date (YYYY-MM-DD). Inclusive lower bound."
```
addedInput schema / properties / filter / properties / direction / description
```
Added value: +"Semantic direction."
```

addedInput schema / properties / filter / properties / merchant / description

Added value: +"Substring match against description or counterparty (case-insensitive)."

addedInput schema / properties / filter / properties / text / description

Added value: +"Whole-row text search over raw transaction fields (case-insensitive)."

addedInput schema / properties / limit / description

Added value: +"Maximum rows to return. Default 20, max 50."

addedInput schema / properties / order / description

Added value: +"Sort direction. Default \"desc\" (largest amount / most recent date first). Only meaningful with sort_by."

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."
```

addedInput schema / properties / sort_by / description

Added value: +"Sort the filtered set before applying limit. \"amount\" ranks by absolute magnitude (signed amounts are still returned). Omit for today's default (encounter order)."

changedOutput schema / $schema

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

Changedlist_transfers10 fields changed

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"

Changedrate_statement9 fields changed

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 / document_id / description

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

addedInput schema / properties / export_format / description

Added value: +"Which output format you exported this conversion to (csv, xlsx, qbo, or xero)."

addedInput schema / properties / feedback / description

Added value: +"Free-text feedback. Only accepted when rating is 3 or below."

addedInput schema / properties / feedback_categories / description

Added value: +"Structured feedback categories. Only accepted when rating is 3 or below."

addedInput schema / properties / rating / description

Added value: +"1-5 star rating for this conversion"

addedInput schema / properties / use_case / description

Added value: +"Tags describing what you use the converted data for."

addedInput schema / properties / use_case_other / description

Added value: +"Free-text use case, for when \"other\" is among the use_case tags."

changedOutput schema / $schema

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

Changedrequest_upload3 fields changed

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"

Changedtime_series22 fields changed

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 / bucket / description
```
Added value: +"Bucket size."
```

addedInput schema / properties / filter / description

Added value: +"Subset of transactions to operate on. All fields are optional and combined with AND logic."

addedInput schema / properties / filter / properties / accounts / description
```
Added value: +"Account number slugs to include."
```
addedInput schema / properties / filter / properties / amountMax / description
```
Added value: +"Inclusive maximum absolute amount."
```
addedInput schema / properties / filter / properties / amountMin / description
```
Added value: +"Inclusive minimum absolute amount."
```

addedInput schema / properties / filter / properties / category / description

Added value: +"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"."

addedInput schema / properties / filter / properties / currency / description
```
Added value: +"ISO 4217 currency code. E.g. \"USD\", \"HKD\"."
```
addedInput schema / properties / filter / properties / dateEnd / description
```
Added value: +"ISO date (YYYY-MM-DD). Inclusive upper bound."
```
addedInput schema / properties / filter / properties / dateStart / description
```
Added value: +"ISO date (YYYY-MM-DD). Inclusive lower bound."
```
addedInput schema / properties / filter / properties / direction / description
```
Added value: +"Semantic direction."
```

addedInput schema / properties / filter / properties / merchant / description

Added value: +"Substring match against description or counterparty (case-insensitive)."

addedInput schema / properties / filter / properties / text / description

Added value: +"Whole-row text search over raw transaction fields (case-insensitive)."

addedInput schema / properties / metric / description
```
Added value: +"Metric per bucket."
```

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"

Changedtop_n23 fields changed

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 / dimension / description
```
Added value: +"Grouping dimension."
```

addedInput schema / properties / filter / description

Added value: +"Subset of transactions to operate on. All fields are optional and combined with AND logic."

addedInput schema / properties / filter / properties / accounts / description
```
Added value: +"Account number slugs to include."
```
addedInput schema / properties / filter / properties / amountMax / description
```
Added value: +"Inclusive maximum absolute amount."
```
addedInput schema / properties / filter / properties / amountMin / description
```
Added value: +"Inclusive minimum absolute amount."
```

addedInput schema / properties / filter / properties / category / description

Added value: +"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"."

addedInput schema / properties / filter / properties / currency / description
```
Added value: +"ISO 4217 currency code. E.g. \"USD\", \"HKD\"."
```
addedInput schema / properties / filter / properties / dateEnd / description
```
Added value: +"ISO date (YYYY-MM-DD). Inclusive upper bound."
```
addedInput schema / properties / filter / properties / dateStart / description
```
Added value: +"ISO date (YYYY-MM-DD). Inclusive lower bound."
```
addedInput schema / properties / filter / properties / direction / description
```
Added value: +"Semantic direction."
```

addedInput schema / properties / filter / properties / merchant / description

Added value: +"Substring match against description or counterparty (case-insensitive)."

addedInput schema / properties / filter / properties / text / description

Added value: +"Whole-row text search over raw transaction fields (case-insensitive)."

addedInput schema / properties / metric / description
```
Added value: +"Metric to rank by."
```

addedInput schema / properties / n / description

Added value: +"Number of top groups to return."

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"

1 tool updateAug 30, 2026

Changedlist_statements2 fields changed

addedOutput schema / properties / documents / items / properties / completedAt

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

changedOutput schema / properties / documents / items / required

Previous value: -[
-  "id",
-  "status",
-  "filename",
-  "pageCount",
-  "createdAt"
-]New value: +[
+  "id",
+  "status",
+  "filename",
+  "pageCount",
+  "createdAt",
+  "completedAt"
+]

1 tool updateAug 27, 2026
- Addeddismiss_statement

1 tool updateAug 24, 2026

Changedlist_transactions2 fields changed

addedInput schema / properties / order

Added value: +{
+  "enum": [
+    "asc",
+    "desc"
+  ],
+  "type": "string"
+}

addedInput schema / properties / sort_by

Added value: +{
+  "enum": [
+    "amount",
+    "date"
+  ],
+  "type": "string"
+}

14 tool updatesAug 21, 2026

Changedaggregate19 fields changed

removedInput schema / properties / filter / description

Removed value: -"Subset of transactions to operate on. All fields are optional and combined with AND logic."

removedInput schema / properties / filter / properties / accounts / description
```
Removed value: -"Account number slugs to include."
```
removedInput schema / properties / filter / properties / amountMax / description
```
Removed value: -"Inclusive maximum absolute amount."
```
removedInput schema / properties / filter / properties / amountMin / description
```
Removed value: -"Inclusive minimum absolute amount."
```

removedInput schema / properties / filter / properties / category / description

Removed value: -"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"."

removedInput schema / properties / filter / properties / currency / description
```
Removed value: -"ISO 4217 currency code. E.g. \"USD\", \"HKD\"."
```
removedInput schema / properties / filter / properties / dateEnd / description
```
Removed value: -"ISO date (YYYY-MM-DD). Inclusive upper bound."
```
removedInput schema / properties / filter / properties / dateStart / description
```
Removed value: -"ISO date (YYYY-MM-DD). Inclusive lower bound."
```
removedInput schema / properties / filter / properties / direction / description
```
Removed value: -"Semantic direction."
```

removedInput schema / properties / filter / properties / merchant / description

Removed value: -"Substring match against description or counterparty (case-insensitive)."

removedInput schema / properties / filter / properties / text / description

Removed value: -"Whole-row text search over raw transaction fields (case-insensitive)."

removedInput schema / properties / metric / description
```
Removed value: -"Aggregation metric."
```

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."
```

Changedcategorize_statement1 field changed
- removedInput schema / properties / document_id / description
```
Removed value: -"Document ID (from convert_statement or list_statements)"
```

Changedcompare30 fields changed

removedInput schema / properties / filterA / description

Removed value: -"Subset of transactions to operate on. All fields are optional and combined with AND logic."

removedInput schema / properties / filterA / properties / accounts / description
```
Removed value: -"Account number slugs to include."
```
removedInput schema / properties / filterA / properties / amountMax / description
```
Removed value: -"Inclusive maximum absolute amount."
```
removedInput schema / properties / filterA / properties / amountMin / description
```
Removed value: -"Inclusive minimum absolute amount."
```

removedInput schema / properties / filterA / properties / category / description

Removed value: -"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"."

removedInput schema / properties / filterA / properties / currency / description
```
Removed value: -"ISO 4217 currency code. E.g. \"USD\", \"HKD\"."
```
removedInput schema / properties / filterA / properties / dateEnd / description
```
Removed value: -"ISO date (YYYY-MM-DD). Inclusive upper bound."
```
removedInput schema / properties / filterA / properties / dateStart / description
```
Removed value: -"ISO date (YYYY-MM-DD). Inclusive lower bound."
```
removedInput schema / properties / filterA / properties / direction / description
```
Removed value: -"Semantic direction."
```

removedInput schema / properties / filterA / properties / merchant / description

Removed value: -"Substring match against description or counterparty (case-insensitive)."

removedInput schema / properties / filterA / properties / text / description

Removed value: -"Whole-row text search over raw transaction fields (case-insensitive)."

removedInput schema / properties / filterB / description

Removed value: -"Subset of transactions to operate on. All fields are optional and combined with AND logic."

removedInput schema / properties / filterB / properties / accounts / description
```
Removed value: -"Account number slugs to include."
```
removedInput schema / properties / filterB / properties / amountMax / description
```
Removed value: -"Inclusive maximum absolute amount."
```
removedInput schema / properties / filterB / properties / amountMin / description
```
Removed value: -"Inclusive minimum absolute amount."
```

removedInput schema / properties / filterB / properties / category / description

Removed value: -"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"."

removedInput schema / properties / filterB / properties / currency / description
```
Removed value: -"ISO 4217 currency code. E.g. \"USD\", \"HKD\"."
```
removedInput schema / properties / filterB / properties / dateEnd / description
```
Removed value: -"ISO date (YYYY-MM-DD). Inclusive upper bound."
```
removedInput schema / properties / filterB / properties / dateStart / description
```
Removed value: -"ISO date (YYYY-MM-DD). Inclusive lower bound."
```
removedInput schema / properties / filterB / properties / direction / description
```
Removed value: -"Semantic direction."
```

removedInput schema / properties / filterB / properties / merchant / description

Removed value: -"Substring match against description or counterparty (case-insensitive)."

removedInput schema / properties / filterB / properties / text / description

Removed value: -"Whole-row text search over raw transaction fields (case-insensitive)."

removedInput schema / properties / metric / description
```
Removed value: -"Metric for both groups."
```

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."
```

Changedconvert_statement11 fields changed

removedInput schema / properties / output_format / description
```
Removed value: -"Output format"
```
removedInput schema / properties / password / description
```
Removed value: -"Password for encrypted PDFs"
```

removedInput schema / properties / pdf / description

Removed value: -"Base64-encoded PDF content — last resort only; prefer pdf_file for an attachment or pdf_url for a link"

removedInput schema / properties / pdf_file / description

Removed value: -"An attached PDF (populated automatically by ChatGPT — do not construct this yourself)."

removedInput schema / properties / pdf_file / properties / download_url / description
```
Removed value: -"Signed URL ChatGPT provides to fetch the attached PDF's bytes."
```
removedInput schema / properties / pdf_file / properties / file_id / description
```
Removed value: -"ChatGPT's identifier for the attached file."
```

removedInput schema / properties / pdf_file / properties / file_name / description

Removed value: -"Original filename of the attached file, when ChatGPT provides one."

removedInput schema / properties / pdf_file / properties / mime_type / description
```
Removed value: -"MIME type of the attached file, when ChatGPT provides one."
```
removedInput schema / properties / pdf_url / description
```
Removed value: -"HTTPS URL to fetch the PDF from"
```

removedInput schema / properties / upload_id / description

Removed value: -"An upload_id from request_upload, after PUTting the file to its upload_url. Use this only when your host has no other way to reference the attached file (no pdf_file/pdf_url equivalent)."

removedInput schema / properties / upload_ids / description

Removed value: -"Batch of upload_ids from a single request_upload(count) call, each already PUT to its own upload_url — converts many statements in one call. Mutually exclusive with pdf, pdf_url, pdf_file, and upload_id. Admission only: the response reports per-file status immediately, never waiting for conversion — fetch results per document_id via get_statement."

Changedevaluate_benchmark16 fields changed

removedInput schema / properties / accounts / description

Removed value: -"Optional account roster for multi-account statements. Each transaction references one via accountId."

removedInput schema / properties / accounts / items / properties / accountNumber / description
```
Removed value: -"Verbatim printed account number — never normalized by the submitter."
```
removedInput schema / properties / accounts / items / properties / currency / description
```
Removed value: -"ISO 4217 currency code."
```

removedInput schema / properties / accounts / items / properties / id / description

Removed value: -"Submission-internal handle, referenced by transactions[].accountId."

removedInput schema / properties / accounts / items / properties / name / description
```
Removed value: -"Verbatim printed account label."
```

removedInput schema / properties / content_hash / description

Removed value: -"SHA-256 hex digest of the PDF. Use statement_id instead if you know it."

removedInput schema / properties / statement_id / description

Removed value: -"Benchmark statement ID (e.g. \"bsb-001\"). Preferred over content_hash."

removedInput schema / properties / transactions / description
```
Removed value: -"Parsed transactions (1-2000)"
```

removedInput schema / properties / transactions / items / properties / accountId / description

Removed value: -"References accounts[].id — the account this transaction belongs to. Omit for single-account statements."

removedInput schema / properties / transactions / items / properties / amount / description

Removed value: -"Transaction amount. Negative = debit, positive = credit (or use direction)."

removedInput schema / properties / transactions / items / properties / balance / description
```
Removed value: -"Running balance after this transaction, if known."
```
removedInput schema / properties / transactions / items / properties / currency / description
```
Removed value: -"ISO 4217 currency code for this transaction, if known."
```
removedInput schema / properties / transactions / items / properties / date / description
```
Removed value: -"ISO 8601 date (YYYY-MM-DD)"
```
removedInput schema / properties / transactions / items / properties / description / description
```
Removed value: -"Transaction description as printed on the statement."
```
removedInput schema / properties / transactions / items / properties / direction / description
```
Removed value: -"Explicit direction. If omitted, inferred from amount sign."
```

removedInput schema / properties / transactions / items / properties / originalData / description

Removed value: -"Raw column values as on the PDF. Omit if unavailable — never fabricate a value; an absence scores the parsed dimension's raw fields 0 rather than polluting the measurement."

Changedget_statement5 fields changed

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"
```

Changedgroup_by20 fields changed

removedInput schema / properties / dimension / description
```
Removed value: -"Grouping dimension."
```

removedInput schema / properties / filter / description

Removed value: -"Subset of transactions to operate on. All fields are optional and combined with AND logic."

removedInput schema / properties / filter / properties / accounts / description
```
Removed value: -"Account number slugs to include."
```
removedInput schema / properties / filter / properties / amountMax / description
```
Removed value: -"Inclusive maximum absolute amount."
```
removedInput schema / properties / filter / properties / amountMin / description
```
Removed value: -"Inclusive minimum absolute amount."
```

removedInput schema / properties / filter / properties / category / description

Removed value: -"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"."

removedInput schema / properties / filter / properties / currency / description
```
Removed value: -"ISO 4217 currency code. E.g. \"USD\", \"HKD\"."
```
removedInput schema / properties / filter / properties / dateEnd / description
```
Removed value: -"ISO date (YYYY-MM-DD). Inclusive upper bound."
```
removedInput schema / properties / filter / properties / dateStart / description
```
Removed value: -"ISO date (YYYY-MM-DD). Inclusive lower bound."
```
removedInput schema / properties / filter / properties / direction / description
```
Removed value: -"Semantic direction."
```

removedInput schema / properties / filter / properties / merchant / description

Removed value: -"Substring match against description or counterparty (case-insensitive)."

removedInput schema / properties / filter / properties / text / description

Removed value: -"Whole-row text search over raw transaction fields (case-insensitive)."

removedInput schema / properties / metric / description
```
Removed value: -"Metric per group."
```

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."
```

Changedlist_statements3 fields changed
- removedInput schema / properties / limit / description
```
Removed value: -"Max results (1-100)"
```
- removedInput schema / properties / offset / description
```
Removed value: -"Pagination offset"
```
- removedInput schema / properties / status / description
```
Removed value: -"Filter by status"
```

Changedlist_transactions19 fields changed

removedInput schema / properties / filter / description

Removed value: -"Subset of transactions to operate on. All fields are optional and combined with AND logic."

removedInput schema / properties / filter / properties / accounts / description
```
Removed value: -"Account number slugs to include."
```
removedInput schema / properties / filter / properties / amountMax / description
```
Removed value: -"Inclusive maximum absolute amount."
```
removedInput schema / properties / filter / properties / amountMin / description
```
Removed value: -"Inclusive minimum absolute amount."
```

removedInput schema / properties / filter / properties / category / description

Removed value: -"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"."

removedInput schema / properties / filter / properties / currency / description
```
Removed value: -"ISO 4217 currency code. E.g. \"USD\", \"HKD\"."
```
removedInput schema / properties / filter / properties / dateEnd / description
```
Removed value: -"ISO date (YYYY-MM-DD). Inclusive upper bound."
```
removedInput schema / properties / filter / properties / dateStart / description
```
Removed value: -"ISO date (YYYY-MM-DD). Inclusive lower bound."
```
removedInput schema / properties / filter / properties / direction / description
```
Removed value: -"Semantic direction."
```

removedInput schema / properties / filter / properties / merchant / description

Removed value: -"Substring match against description or counterparty (case-insensitive)."

removedInput schema / properties / filter / properties / text / description

Removed value: -"Whole-row text search over raw transaction fields (case-insensitive)."

removedInput schema / properties / limit / description

Removed value: -"Maximum rows to return. Default 20, max 50."

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."
```

Changedlist_transfers8 fields changed

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."
```

Changedrate_statement7 fields changed

removedInput schema / properties / document_id / description

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

removedInput schema / properties / export_format / description

Removed value: -"Which output format you exported this conversion to (csv, xlsx, qbo, or xero)."

removedInput schema / properties / feedback / description

Removed value: -"Free-text feedback. Only accepted when rating is 3 or below."

removedInput schema / properties / feedback_categories / description

Removed value: -"Structured feedback categories. Only accepted when rating is 3 or below."

removedInput schema / properties / rating / description

Removed value: -"1-5 star rating for this conversion"

removedInput schema / properties / use_case / description

Removed value: -"Tags describing what you use the converted data for."

removedInput schema / properties / use_case_other / description

Removed value: -"Free-text use case, for when \"other\" is among the use_case tags."

Changedrequest_upload1 field changed

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."

Changedtime_series20 fields changed

removedInput schema / properties / bucket / description
```
Removed value: -"Bucket size."
```

removedInput schema / properties / filter / description

Removed value: -"Subset of transactions to operate on. All fields are optional and combined with AND logic."

removedInput schema / properties / filter / properties / accounts / description
```
Removed value: -"Account number slugs to include."
```
removedInput schema / properties / filter / properties / amountMax / description
```
Removed value: -"Inclusive maximum absolute amount."
```
removedInput schema / properties / filter / properties / amountMin / description
```
Removed value: -"Inclusive minimum absolute amount."
```

removedInput schema / properties / filter / properties / category / description

Removed value: -"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"."

removedInput schema / properties / filter / properties / currency / description
```
Removed value: -"ISO 4217 currency code. E.g. \"USD\", \"HKD\"."
```
removedInput schema / properties / filter / properties / dateEnd / description
```
Removed value: -"ISO date (YYYY-MM-DD). Inclusive upper bound."
```
removedInput schema / properties / filter / properties / dateStart / description
```
Removed value: -"ISO date (YYYY-MM-DD). Inclusive lower bound."
```
removedInput schema / properties / filter / properties / direction / description
```
Removed value: -"Semantic direction."
```

removedInput schema / properties / filter / properties / merchant / description

Removed value: -"Substring match against description or counterparty (case-insensitive)."

removedInput schema / properties / filter / properties / text / description

Removed value: -"Whole-row text search over raw transaction fields (case-insensitive)."

removedInput schema / properties / metric / description
```
Removed value: -"Metric per bucket."
```

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."
```

Changedtop_n21 fields changed

removedInput schema / properties / dimension / description
```
Removed value: -"Grouping dimension."
```

removedInput schema / properties / filter / description

Removed value: -"Subset of transactions to operate on. All fields are optional and combined with AND logic."

removedInput schema / properties / filter / properties / accounts / description
```
Removed value: -"Account number slugs to include."
```
removedInput schema / properties / filter / properties / amountMax / description
```
Removed value: -"Inclusive maximum absolute amount."
```
removedInput schema / properties / filter / properties / amountMin / description
```
Removed value: -"Inclusive minimum absolute amount."
```

removedInput schema / properties / filter / properties / category / description

Removed value: -"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"."

removedInput schema / properties / filter / properties / currency / description
```
Removed value: -"ISO 4217 currency code. E.g. \"USD\", \"HKD\"."
```
removedInput schema / properties / filter / properties / dateEnd / description
```
Removed value: -"ISO date (YYYY-MM-DD). Inclusive upper bound."
```
removedInput schema / properties / filter / properties / dateStart / description
```
Removed value: -"ISO date (YYYY-MM-DD). Inclusive lower bound."
```
removedInput schema / properties / filter / properties / direction / description
```
Removed value: -"Semantic direction."
```

removedInput schema / properties / filter / properties / merchant / description

Removed value: -"Substring match against description or counterparty (case-insensitive)."

removedInput schema / properties / filter / properties / text / description

Removed value: -"Whole-row text search over raw transaction fields (case-insensitive)."

removedInput schema / properties / metric / description
```
Removed value: -"Metric to rank by."
```

removedInput schema / properties / n / description

Removed value: -"Number of top groups to return."

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."
```

4 tool updatesAug 17, 2026

Changedconvert_statement2 fields changed

addedInput schema / properties / upload_ids

Added value: +{
+  "description": "Batch of upload_ids from a single request_upload(count) call, each already PUT to its own upload_url — converts many statements in one call. Mutually exclusive with pdf, pdf_url, pdf_file, and upload_id. Admission only: the response reports per-file status immediately, never waiting for conversion — fetch results per document_id via get_statement.",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 100,
+  "minItems": 1,
+  "type": "array"
+}

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"
+}

Changedget_credits2 fields changed

addedOutput schema / properties / plan

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "dailySpendCap": {
+      "anyOf": [
+        {
+          "type": "number"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "maxPagesPerUpload": {
+      "type": "number"
+    },
+    "maxUploadSizeMb": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "maxPagesPerUpload",
+    "maxUploadSizeMb",
+    "dailySpendCap"
+  ],
+  "type": "object"
+}

changedOutput schema / required

Previous value: -[
-  "balance",
-  "limit",
-  "planId",
-  "creditsExpireAt",
-  "summary"
-]New value: +[
+  "balance",
+  "limit",
+  "planId",
+  "creditsExpireAt",
+  "plan",
+  "summary"
+]

Changedget_statement1 field changed

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"
+}

Changedrequest_upload3 fields changed

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"
-]

1 tool updateAug 13, 2026

Changedlist_transfers2 fields changed

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"
+}

15 tool updatesAug 12, 2026
- First observedaggregate
- First observedcategorize_statement
- First observedcompare
- First observedconvert_statement
- First observedevaluate_benchmark
- First observedget_credits
- First observedget_statement
- First observedgroup_by
- First observedlist_statements
- First observedlist_transactions
- First observedlist_transfers
- First observedrate_statement
- First observedrequest_upload
- First observedtime_series
- First observedtop_n

Frequently Asked Questions

Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.

Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
- GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
- HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
- DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.

The HTTP ownership file has this structure:

{
  "$schema": "https://glama.ai/mcp/schemas/connector.json",
  "claim": "glama_claim_..."
}

Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.

If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.

For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.

Discussions

No comments yet. Be the first to start the discussion!

Related MCP Connectors

MainBook Bank Statement Converter A
ai.mainbook
Convert PDF bank statements to checked Excel, CSV or JSON with balance validation.
Finance File Systems Data Platforms
41
Statement to Budget A
com.statementtobudget.www
Turn bank statement PDFs, CSVs, XLSX and OFX into categorised transactions plus a summary.
Finance Data Platforms
31
Document to JSON – PDF Invoice/Statement/Contract ParserOAuth
io.github.fashionmascherine-svg
Turn any PDF into structured JSON via AI + OCR: invoices, bank statements, contracts.
Finance AI & Machine Learning
28
AllPDFMagic A
com.allpdfmagic
PDF tools + invoice extraction, bank statement parsing, GST reconciliation & GSTIN validation.
Finance Documentation Access
72

Related MCP Servers

CapyParse MCP Server
Finance Data Platforms
remotenodelabs
A
license
A
quality
C
maintenance
Converts PDF bank statements into structured data (Markdown, JSON, CSV, JSONL) with verified transactions and balance checks, enabling agents to audit numbers.
Updated 2 months ago (2026-07-12 02:52 UTC)
5
20
MIT
MainBook Bank Statement
Finance File Systems
human-beyond
A
license
A
quality
A
maintenance
Converts customer-supplied PDF bank statements into checked Excel, CSV, or JSON with balance validation. Runs locally with your own MainBook API key or against MainBook's hosted endpoint, and it never connects to bank accounts.
Updated 3 days ago (2026-09-02 23:37 UTC)
5
MIT
document-to-json-mcp
Data Platforms AI & Machine Learning
fashionmascherine-svg
A
license
A
quality
B
maintenance
Convert PDFs to structured JSON. Extract invoices, bank statements, contracts, and more. Pay per call via x402 USDC.
Updated 2 months ago (2026-06-25 16:25 UTC)
5
8
MIT
taxformatter-mcp-server
Finance Cryptocurrency Data Platforms
Sean-Bravo
A
license
Not graded
quality
C
maintenance
Parse crypto exchange CSVs (Coinbase, Binance, Kraken, +11 more) and bank statement PDFs (Chase, BofA, +11 more) into Koinly, TurboTax, CoinLedger, or ZenLedger formats. Free tier: 25 files/month, no credit card required.
Updated 3 months ago (2026-05-23 18:03 UTC)
3
ISC

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.

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Frequently Asked Questions

Discussions

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources