Bankstatemently
Server Details
Convert PDF bank statements into structured transactions, accounts, and balances.
- Status
- Healthy
- Uptime
- 99.9% over 41 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- bankstatemently/plugins
- GitHub Stars
- 1
- Server Listing
- bankstatemently
TDQS
Scored across 16 tools
Most tools are clearly distinct (convert/get/list/dismiss/rate/categorize cover the document lifecycle; aggregate/group_by/time_series/top_n/compare are analysis variants). However, aggregate, group_by, time_series, top_n, and compare all compute metrics over filtered transactions with overlapping scope parameters, so an agent could confuse which analytic to pick.
Tool names predominantly follow verb_noun (convert_statement, get_statement, list_transactions, request_upload, rate_statement). Minor deviations: aggregate, compare, group_by, time_series, and top_n are verb/prepositional phrases without a noun object, but they form a coherent analytics family.
16 tools is at the upper edge of comfortable scope, but each tool maps to a distinct operation in the bank-statement domain (convert, fetch, list, rate, categorize, analyze, upload, benchmark). A few analysis tools could be consolidated, but the count is not unreasonable.
The domain surface is well covered: conversion, retrieval, listing, dismissal, rating, categorization, upload, credit monitoring, and a rich analytics layer. Minor gaps include no explicit document deletion (by design) and no tool to modify/update converted transaction data, but these are workable or intentional.
Available Tools
16 toolsaggregateAggregate TransactionsARead-onlyInspect
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.
| 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). | |
| filter | No | Subset of transactions to operate on. All fields are optional and combined with AND logic. | |
| metric | Yes | Aggregation metric. |
Output Schema
| Name | Required | Description |
|---|---|---|
| scope | Yes | |
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint and destructiveHint already set, the description adds the important behavioral caveat that results are per-currency and must never be summed manually, plus the default scope of all completed statements. That is genuinely useful behavioral disclosure beyond the annotations, and it does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the core purpose and metric list, the second conveys the most critical behavioral rule, and the last handles an alternative. No sentence repeats schema content, and nothing is extraneous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a non-destructive aggregation tool with a fully described schema and an output schema, the description covers the needed context: default scope, filtering, the per-currency danger, and the correct sibling for a different class of question. The nested filter object and output shape are already documented in the schema, so nothing agent-critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds semantic value: it clarifies the purpose of scope (narrowing by accounts/products and date range), calls attention to a 'filtered set', and warns about per-currency handling, which directly impacts use of metric. These additions are not purely redundant with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a concrete verb and resource: "Compute a single metric ... over a filtered set of transactions across your converted statements." It lists the five possible metrics and clearly contrasts the tool with get_credits, while the phrase "single metric" distinguishes it from bucket-producing siblings like group_by and time_series.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly routes non-transaction quota/credit questions to get_credits and explains the mutable default scope and how to narrow it. It does not explicitly mention sibling tools like group_by, time_series, or top_n, but the 'single metric' wording strongly implies they are for different use cases, so agents have to infer the boundary with them.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes | Document ID (from convert_statement or list_statements) |
Output Schema
| Name | Required | Description |
|---|---|---|
| hint | No | |
| error | No | |
| status | Yes | |
| message | No | |
| summary | No | |
| documentId | No | |
| categoryMappings | No |
TDQS
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.
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.
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.
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.
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.
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 GroupsARead-onlyInspect
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.
| 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). | |
| 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
| Name | Required | Description |
|---|---|---|
| scope | Yes | |
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds the default-scope behavior ('Scope defaults to all your completed statements') and the ability to narrow via 'scope'. This is meaningful context beyond the annotations, though it does not address rate limits or auth, which are less critical given the read-only safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero filler. The core purpose is front-loaded, and the scope behavior is stated efficiently. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters (including nested objects) and an output schema, the description is reasonably complete. It explains the default scope and the general comparison intent, and the schema covers parameter details. It does not mention edge cases or limitations (e.g., max number of results), but these are minor given the read-only nature and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 a usage example ('one category vs another') that clarifies the intended semantics of filterA/filterB, and it explains the default scope for the 'scope' parameter. However, it does not significantly compensate beyond what the schema already documents, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Side-by-side metric comparison for two filtered groups of transactions' and provides concrete examples ('one category vs another, one month vs another'). This distinguishes it from siblings like aggregate (single group) and group_by (grouping), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by its clear definition and examples, but does not explicitly state when to prefer this over alternatives (e.g., aggregate for one group). It does provide context on the default scope and how to narrow it, which aids decision-making, though it lacks explicit exclusion criteria.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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
| 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 | |
| elapsedMs | No | |
| exportUrl | No | |
| documentId | No | |
| pagination | No | |
| transactions | No | |
| confidenceScore | No | |
| estimateSeconds | No | |
| processingStage | No | |
| transactionCount | No | |
| processingProgress | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false and destructiveHint=false, so the description carries the burden of behavioral disclosure and delivers richly: it discloses that batch mode 'only ADMITS each file' and returns immediately, that non-json formats return a time-limited download link, that the summary field is the single source of truth, that credits are consumed at 1 per page with plan-dependent page limits, and that responses must never echo raw status values. No contradiction exists between the description and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place given the tool's genuine complexity: input-method resolution, batch vs. single semantics, output-format behavior, translation rules, and pricing. However, it is a single dense unbroken paragraph; bullet-style structuring of the input-method rules would improve scannability without adding words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given high complexity (7 parameters, batch mode, 5 output formats, 16 siblings) and a present output schema, the description covers nearly everything an agent needs: all input reference pathways, batch admit-only behavior with the get_statement handoff, inline vs. download-link output behavior, credit cost, and the summary-field contract. Minor gaps such as failure/error handling and the exact shape of the summary field are acceptable since an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, giving a baseline of 3, and the description adds real value beyond the schema: it establishes a priority order among pdf_file/pdf_url/upload_id/base64 pdf, clarifies that pdf_file is auto-populated and must never be self-encoded, and explains the admission-only semantics and mutual exclusivity of upload_ids. It does not add per-parameter syntax details beyond the schema, but the orchestration-level semantics it provides are substantial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource+outcome: 'Convert a bank statement PDF into structured data or a spreadsheet.' This unambiguously distinguishes it from siblings like get_statement (retrieving results), request_upload (uploading files), and categorize_statement (post-conversion analysis). The name, title, and description align without the description merely restating the title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance for every input method: pdf_file arrives automatically for attachments, pdf_url for public HTTPS links, upload_id only when the host lacks attachment references, base64 as a declared last resort, and upload_ids for batching. It explicitly names the alternative follow-up: 'call get_statement per document_id once ready rather than expecting inline results here,' and states that batch mode is mutual-exclusive with the single-file parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dismiss_statementDismiss StatementADestructiveInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes | Document ID from list_statements, convert_statement, or get_statement |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| summary | Yes | |
| documentId | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the annotations: it clarifies that the operation marks the document as dismissed and leaves stored data/artifacts untouched, which is important given destructiveHint=true. It doesn't fully describe side effects like whether the dismissal is reversible, but the key behavioral trait is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the action, the usage condition, and the non-delete clarification. Front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with a clear purpose and annotations, the description is nearly complete. It could mention whether the dismissal can be undone, but the core context needed to invoke it correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the only parameter (document_id) is already described in the schema. The description doesn't add extra parameter-level detail, but with a single well-documented parameter, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Hide a failed, rejected, or cancelled document from future list_statements results') with a specific verb and resource. It also distinguishes itself from a delete operation, which is important given the sibling tools and the destructiveHint annotation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it ('only when the user asks to clear a terminal failed/rejected/cancelled conversion from their history') and what it is not ('This is not a delete'). This gives clear guidance for an agent to select this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
evaluate_benchmarkEvaluate BenchmarkARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| challenges | Yes | |
| difficulty | Yes | |
| contentHash | No | |
| parsedScore | Yes | |
| datasetVersion | No | |
| normalizedScore | Yes |
TDQS
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 meaningful behavioral context beyond that: the published-only restriction, the held-out error behavior, the scoring rule that absent originalData zeroes the raw-fidelity dimension, the explicit 'never fabricate a value' instruction, and the 'free to use — no credits consumed' note. These are exactly the behavioral traits an agent needs to know and cannot infer from annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, identifiers, return values, published-only constraint, originalData guidance, cost note, and catalog pointer. It is front-loaded with the core purpose and the most decision-relevant constraint (published-only) appears early. It loses one point for being slightly long and for burying the 'read the catalog first' instruction at the end, which is arguably the first thing an agent should do.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a benchmark-evaluation tool with a rich output schema, the description covers everything an agent needs to call it correctly: what to pass, which identifier to prefer, the published-only gate, the originalData fidelity rule, the no-fabrication constraint, and the cost implication. The output schema exists, so the description needn't enumerate return fields. The only minor gap is that it doesn't explicitly say what happens if both statement_id and content_hash are omitted, but the schema's required field is transactions, so that's not a real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 four parameters well. The description adds value by clarifying the relationship between statement_id and content_hash ('Use statement_id instead if you know it'), by explaining the originalData scoring consequence, and by emphasizing that originalData should be passed verbatim. It doesn't add much about accounts or transactions, but the schema already covers those thoroughly, so the baseline-3-plus-incremental-value score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 immediately distinguishes this from sibling tools like rate_statement or categorize_statement by naming the benchmark context. It also names the two accepted identifiers (statement_id, content_hash) and the returned metrics, so an agent can tell exactly what this tool does and what it produces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: only statements marked published: true can be evaluated, held-out statements error, and the agent should read the benchmark://catalog resource first. It also gives a concrete workflow hint — fetch originalData via get_statement with data_mode: 'original' and pass it through verbatim — which routes the agent to the correct sibling tool and mode. This is unusually actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_creditsGet Credit BalanceARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| plan | Yes | |
| limit | Yes | |
| planId | Yes | |
| balance | Yes | |
| granted | Yes | |
| summary | Yes | |
| creditsExpireAt | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable context beyond that: it defines a credit as '1 credit = 1 page of bank statement processing' and notes it reports additional operational limits for batch sizing. This enriches agent understanding without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core definition, followed by usage guidance and a clarifying unit, and finally additional context about plan limits. Every sentence adds value without redundancy. It is efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are no parameters and an output schema exists, the description sufficiently covers what the tool does, when to use it, and what it returns (credits and plan limits). It provides enough context for an agent to decide to call it and understand the meaning of the results. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no parameter details. The baseline for 0 parameters is 4 per the rubric. The description does not need to add parameter semantics since none exist, and it focuses on the return value, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'remaining Bankstatemently credits — the processing quota, NOT credit/debit transactions,' which precisely defines the resource and avoids confusion with transaction credits. It also explains it reports operational plan limits, giving a specific noun and scope. This distinguishes it from sibling tools like list_transactions 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists use cases: 'how many credits do I have, remaining pages, plan limits, quota, how many pages can I upload.' It also clarifies the exclusion: 'NOT credit/debit transactions,' which serves as a when-not-to-use guideline. While it doesn't name alternative tools, the explicit use-case list and negation make selection unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_statementGet Statement DataARead-onlyInspect
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.
| 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
| 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 | |
| elapsedMs | No | |
| exportUrl | No | |
| documentId | No | |
| pagination | No | |
| transactions | No | |
| confidenceScore | No | |
| estimateSeconds | No | |
| processingStage | No | |
| transactionCount | No | |
| processingProgress | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals important behaviors beyond the readOnlyHint annotation: json output is inline while other formats return time-limited download links, the summary field is the single source of truth, responses must be translated faithfully, and raw status values/field names should never be echoed. This is substantial behavioral context that annotations alone do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but it is dense with necessary guidance for a tool with multiple output formats, data modes, and cross-tool integration with evaluate_benchmark. It is front-loaded with the core purpose and usage, then expands into format-specific and benchmark-specific details. A few rules (like translation and not echoing raw values) could be seen as extra, but they are operationally relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, an output schema, and multiple format-dependent behaviors, the description covers the essential decision points: when to call it, which data_mode to choose, how each output format behaves, and how to handle the summary field. Pagination defaults are already in the schema, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds meaningful semantics on top: what output_format json does differently from the other formats, how data_mode selects projections, and why 'original' matters for evaluate_benchmark. This goes beyond the schema's enum labels and default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair: 'Fetch the full converted data for a previously processed document.' It clearly distinguishes itself from convert_statement by stating it is used after that tool returns a 'processing' status, so an agent can tell when get_statement is the right call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use the tool ('after convert_statement returns a processing status, or to re-fetch results') and when to fetch data_mode 'original' ('when you plan to submit results to evaluate_benchmark'). This gives direct routing guidance rather than leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
group_byGroup TransactionsARead-onlyInspect
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.
| 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). | |
| 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
| Name | Required | Description |
|---|---|---|
| scope | Yes | |
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds behavioral details beyond annotations: results are per-currency and the scope defaults to all completed statements. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with strong front-loading: the first sentence states the core function (grouping and metrics), the second covers scope and default behavior. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema (100% coverage) and the presence of an output schema, the description sufficiently explains the tool's behavior. It covers default scope, per-currency results, and the scope parameter, leaving no critical gaps for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are fully documented. The description adds minimal extra meaning—it mentions that scope narrows to accounts/products and/or date range, but this is already in the schema. It does not provide additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact operation: grouping transactions by a dimension (listing all five) and applying a metric (implied list). It also specifies that results are per-currency and the default scope, making the tool's purpose unmistakable and distinct from siblings like top_n or time_series.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: it groups transactions by dimension with a metric, and explains the default scope (all completed statements) and how to narrow it via the 'scope' parameter. However, it does not explicitly name alternative tools or state when not to use it, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_statementsList StatementsARead-onlyInspect
Browse your previously converted bank statements with pagination and optional status filter.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (1-100) | |
| offset | No | Pagination offset | |
| status | No | Filter by status |
Output Schema
| Name | Required | Description |
|---|---|---|
| documents | Yes | |
| pagination | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the scope 'previously converted' and mentions pagination, but does not disclose additional behaviors like ordering, default limits, or what happens when no status filter is applied. This is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence states the primary purpose and key features without repetition or filler. Every word earns its place, and the structure is immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, all three optional parameters documented in the schema, and annotations declaring read-only behavior, the description is nearly complete for a low-complexity list tool. The only slight gap is the ambiguous phrase 'previously converted,' which could conflict with the status filter enum including 'processing' and 'failed,' leaving the exact set of returned records slightly unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents limit, offset, and status with defaults and constraints. The description's mention of 'pagination and optional status filter' reinforces the parameter groups but adds no new semantic detail beyond the schema, matching the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'browse' with the resource 'previously converted bank statements' and mentions pagination and status filtering. This clearly differentiates the tool from siblings like list_transactions, list_transfers, and get_statement by scope and resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'previously converted bank statements' implies the tool is for browsing existing conversion records, providing a usage context. However, it does not explicitly state when to choose this over alternatives such as get_statement or list_transactions, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_transactionsList TransactionsARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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
| Name | Required | Description |
|---|---|---|
| scope | Yes | |
| transactions | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds meaningful behavioral detail: the 50-row cap, the actual evaluated scope returned in every response, and the content_hash on each row for citation. This goes beyond the schema and annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: the transaction definition is conceptually necessary, the cap and scope defaults are actionable, the response behavior is useful for citing results, and the get_credits redirect prevents misuse. The structure is front-loaded and free of padded language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the complex nested scope schema, the description covers defaults, limits, behavior, and the main alternative tool. With a rich input schema, an output schema, and safety annotations present, nothing essential is missing for an agent to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents limit, order, scope, filter, and sort_by in detail. The description mentions the scope object's role but does not need to add parameter-level meaning; it stays at the expected baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Return a filtered list of transactions') and defines exactly what a transaction is, distinguishing it from a transfer or statement concept. It also clearly scopes the operation to converted statements, making the tool's purpose unambiguous relative to siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear when-to-use context: default scope is all completed statements, and scope can narrow by accounts/products or date range. It explicitly routes credit/quota questions to get_credits, but it does not contrast with list_transfers or other list-style siblings, so the exclusion is partial rather than exhaustive.
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 AccountsARead-onlyInspect
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.
| 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
| Name | Required | Description |
|---|---|---|
| scope | Yes | |
| ambiguous | Yes | |
| transfers | Yes | |
| unmatched | No | |
| ambiguousCount | Yes | |
| matchWindowDays | Yes | |
| accountSuccessions | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond that: it explains that the tool reports the match window used even when no transfers are found, ensuring no silent lack of results; and it details that with 'amountMin' the response includes an 'unmatched' bucket for large movements without a matching counterpart. This provides transparency about the tool's behavior and edge cases, which is not derivable from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but structured coherently, with the main purpose and key guidance front-loaded. It is dense with important information but avoids redundancy. Minor trimming could improve conciseness, but it is not bloated with fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two-parameter, nested schema, output schema present), the description provides complete guidance: it defines what a transfer is, distinguishes from non-transfers, gives clear usage instructions, explains the effect of both parameters, and notes the tool always reports the match window. The output schema covers return values, so the description need not explain them. It lacks nothing an agent needs to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, so both parameters are documented in the schema. The description adds some context by explaining the effect of 'scope' (narrow to specific accounts/products and/or date range) and 'amountMin' (flooring transfers and adding unmatched bucket), but it doesn't add significant new meaning beyond what the schema already provides. The baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool matches transfers between the user's own accounts, defining a transfer as two transactions (debit and credit) matched by amount and date, plus account successions. It explicitly distinguishes from payments to outside parties, and it positions itself as the definitive tool for 'money moved between my accounts' questions, unlike list_transactions. This makes the purpose specific and unambiguous, and it differentiates from sibling tools like list_transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs when to use this tool: 'THE way to answer any 'was money moved between my accounts' question' and 'never try to answer a money-moved-between-accounts question with list_transactions + arithmetic; always call this tool instead.' It also provides additional guidance on how to use the 'scope' parameter to narrow results and when to pass 'amountMin' for unmatched movements. This is explicit and actionable.
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 without clearing feedback already submitted for 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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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
| Name | Required | Description |
|---|---|---|
| hint | No | |
| error | No | |
| rating | No | |
| status | Yes | |
| message | No | |
| summary | No | |
| useCase | No | |
| documentId | No | |
| hasFeedback | No | |
| useCaseOther | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations convey only that this is a mutating, non-destructive action, so the description adds real value by explaining the re-call/update behavior, that prior feedback is retained, and that the returned state is the source of truth. It also explicitly directs agents to rely on the `summary` field. It could go slightly further on failure behavior or side effects, but the upside is good.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences and every sentence earns its place, covering purpose, the conditional feedback constraint, the update behavior, and how to interpret the response. No filler, redundant examples, or redundant schema repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7-parameter schema, 100% schema coverage, and an output schema, the description provides the missing behavioral context needed for correct invocation and response interpretation. It could be improved by explicitly stating that the document_id must belong to a conversion performed by the caller, but it is still adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 every parameter. The description restates the conditional feedback rule already present in the schema and broadly mentions use-case tags, but it does not add much new meaning about parameters like export_format or use_case_other, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: report how well a previously converted bank statement was parsed, with a 1-5 rating, optional feedback, and use-case tags. It is unambiguous and reads distinctly from the sibling tools, though it does not explicitly name or differentiate itself from a sibling like evaluate_benchmark.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the usage context clear: rate an already converted statement, and re-calling updates the existing rating. It also warns that there is no separate read-back tool, which guides an agent toward using the response for that purpose. It does not explicitly list alternatives or when-not-to-use scenarios, but the tool's role is fairly self-contained.
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).
| 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
| Name | Required | Description |
|---|---|---|
| uploads | No | |
| max_bytes | No | |
| upload_id | No | |
| expires_at | No | |
| upload_url | No |
TDQS
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.
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.
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.
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.
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.
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 SeriesARead-onlyInspect
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.
| 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). | |
| 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
| Name | Required | Description |
|---|---|---|
| scope | Yes | |
| result | Yes |
TDQS
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 that the default scope is all completed statements and that filtering is via scope, which is useful. It doesn't mention output structure, but with an output schema present, that's less critical. The description doesn't contradict annotations and adds some context beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences, with the core purpose front-loaded. The first sentence clearly states what the tool does)Skip the second adds essential context on scope defaults. It's efficient with no fluff, but could be slightly more structured with explicit when-to-use guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with an output schema, 4 parameters, and nested objects, the description is adequate. It explains the core operation, the scope mechanism, and the default behavior. It doesn't detail return format, but output schema covers that. The only missing piece is explicit differentiation from siblings, but the description's clarity on time-series makes it usable. Overall, it's complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so every parameter is documented in the schema. The description adds meaning by explaining that bucket groups into week/month and metric is applied per bucket, and that scope narrows to specific accounts/products and date range. It also clarifies that scope defaults to all completed statements, which is not in the schema. This adds value beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool computes a time series by grouping transactions into week/month buckets and applying a metric, which is a specific verb plus resource. It also mentions it's for trends, and the scope default is clear. This distinguishes it from siblings like group_by or top_n because it focuses on temporal bucketing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states when to use it (for trends over time) and how to narrow the scope (pass 'scope'). It doesn't explicitly name alternatives, but the sibling list includes group_by and top_n which are related; the description implies the distinguishing factor is time series. It could be improved by explicitly saying 'use this instead of group_by when you need time-bucketed aggregation'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
top_nTop N TransactionsARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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
| Name | Required | Description |
|---|---|---|
| scope | Yes | |
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds a useful default-scope behavior and per-currency nuance for monetary metrics, but does not disclose pagination, ordering details beyond descending, or near the result shape beyond what the output schema already provides. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver the core behavior first and then the scope control, with no filler. The purpose is front-loaded and every clause adds relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a rich input schema and an output schema, the description is largely sufficient: it orients the agent to the top-N ranking, default scope, and narrowing options. It is slightly less complete because it does not position top_n relative to its analysis-heavy siblings, but that gap is secondary given the schema clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so parameters are already fully described. The description adds a small amount of extra meaning by restating the scope default and noting per-currency behavior, but it mostly repeats schema-level information, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action and resource: return the top N groups ranked by metric in descending order, with a per-currency qualification for monetary metrics. This clearly distinguishes from broader sibling tools like aggregate, group_by, or list_transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives useful context about the default scope and how to narrow it with accounts/products/date range, but it never states when to prefer top_n over group_by, aggregate, or compare, nor any when-not-to-use conditions. The usage guidance is therefore implied rather than explicit.
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.
1 tool update
- Changed
get_credits4 fields changed- added
Output schema / properties / grantedAdded value: +{ + "type": "number" +} - added
Output schema / properties / plan / properties / monthlyPagesAdded value: +{ + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] +} - changed
Output schema / properties / plan / requiredPrevious value: -[ - "maxPagesPerUpload", - "maxUploadSizeMb", - "dailySpendCap" -]New value: +[ + "maxPagesPerUpload", + "maxUploadSizeMb", + "dailySpendCap", + "monthlyPages" +] - changed
Output schema / requiredPrevious value: -[ - "balance", - "limit", - "planId", - "creditsExpireAt", - "plan", - "summary" -]New value: +[ + "balance", + "limit", + "granted", + "planId", + "creditsExpireAt", + "plan", + "summary" +]
3 tool updates
- Changed
convert_statement5 fields changed- removed
Output schema / properties / completedAtRemoved value: -{ - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] -} - removed
Output schema / properties / createdAtRemoved value: -{ - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] -} - removed
Output schema / properties / extractionRemoved value: -{ - "additionalProperties": false, - "properties": { - "method": { - "enum": [ - "rule", - "vlm", - "precomputed" - ], - "type": "string" - }, - "pageCount": { - "type": "number" - } - }, - "required": [ - "method", - "pageCount" - ], - "type": "object" -} - removed
Output schema / properties / processedAtRemoved value: -{ - "type": "string" -} - removed
Output schema / properties / processingTimeMsRemoved value: -{ - "type": "number" -}
- Changed
get_statement5 fields changed- removed
Output schema / properties / completedAtRemoved value: -{ - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] -} - removed
Output schema / properties / createdAtRemoved value: -{ - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] -} - removed
Output schema / properties / extractionRemoved value: -{ - "additionalProperties": false, - "properties": { - "method": { - "enum": [ - "rule", - "vlm", - "precomputed" - ], - "type": "string" - }, - "pageCount": { - "type": "number" - } - }, - "required": [ - "method", - "pageCount" - ], - "type": "object" -} - removed
Output schema / properties / processedAtRemoved value: -{ - "type": "string" -} - removed
Output schema / properties / processingTimeMsRemoved value: -{ - "type": "number" -}
- Changed
list_statements1 field changed- removed
Output schema / properties / documents / items / properties / completedAtRemoved value: -{ - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] -}
11 tool updates
- Changed
aggregate3 fields changed- added
Output schema / $defsAdded value: +{ + "__schema0": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "number" + }, + { + "type": "boolean" + }, + { + "type": "null" + }, + { + "items": { + "$ref": "#/$defs/__schema0" + }, + "type": "array" + }, + { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + } + ] + } +} - changed
Output schema / properties / result / anyOfPrevious value: -[ - { - "additionalProperties": {}, - "properties": {}, - "type": "object" - }, - { - "items": { - "additionalProperties": {}, - "properties": {}, - "type": "object" - }, - "type": "array" - } -]New value: +[ + { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + { + "items": { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "type": "array" + } +] - changed
Output schema / properties / scope / additionalPropertiesPrevious value: -{}New value: +false
- Changed
compare3 fields changed- added
Output schema / $defsAdded value: +{ + "__schema0": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "number" + }, + { + "type": "boolean" + }, + { + "type": "null" + }, + { + "items": { + "$ref": "#/$defs/__schema0" + }, + "type": "array" + }, + { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + } + ] + } +} - changed
Output schema / properties / result / anyOfPrevious value: -[ - { - "additionalProperties": {}, - "properties": {}, - "type": "object" - }, - { - "items": { - "additionalProperties": {}, - "properties": {}, - "type": "object" - }, - "type": "array" - } -]New value: +[ + { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + { + "items": { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "type": "array" + } +] - changed
Output schema / properties / scope / additionalPropertiesPrevious value: -{}New value: +false
- Changed
convert_statement23 fields changed- added
Output schema / $defsAdded value: +{ + "__schema0": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "number" + }, + { + "type": "boolean" + }, + { + "type": "null" + }, + { + "items": { + "$ref": "#/$defs/__schema0" + }, + "type": "array" + }, + { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + } + ] + } +} - changed
Output schema / properties / columns / items / additionalPropertiesPrevious value: -{}New value: +false - added
Output schema / properties / completedAtAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / createdAtAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / document / properties / bankAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / document / properties / bankIdAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / document / properties / countryAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / document / properties / currencyAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / document / properties / documentTypeAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / document / properties / languagesAdded value: +{ + "anyOf": [ + { + "items": { + "type": "string" + }, + "type": "array" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / document / properties / pageCountAdded value: +{ + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / document / properties / statementDateAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / document / properties / statementPeriodAdded value: +{ + "additionalProperties": false, + "properties": { + "from": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "to": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "from", + "to" + ], + "type": "object" +} - added
Output schema / properties / document / properties / statementsAdded value: +{ + "items": { + "additionalProperties": {}, + "properties": { + "date": { + "type": "string" + }, + "period": { + "additionalProperties": false, + "properties": { + "from": { + "type": "string" + }, + "to": { + "type": "string" + } + }, + "required": [ + "from", + "to" + ], + "type": "object" + }, + "products": { + "items": { + "additionalProperties": {}, + "properties": { + "accounts": { + "items": { + "additionalProperties": false, + "properties": { + "accountHolderName": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "accountId": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "accountNumber": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "cardNumber": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "categories": { + "items": { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "type": "array" + }, + "currency": { + "type": "string" + }, + "declared": { + "items": { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "type": "array" + }, + "totals": { + "additionalProperties": false, + "properties": { + "closingBalance": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "openingBalance": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "totalCredits": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "totalDebits": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + } + }, + "type": "object" + }, + "transactions": { + "items": { + "additionalProperties": false, + "properties": { + "accountId": { + "type": "number" + }, + "amount": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "string" + } + ] + }, + "balance": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "string" + } + ] + }, + "category": { + "type": "string" + }, + "checkNumber": { + "type": "string" + }, + "currency": { + "type": "string" + }, + "date": { + "type": "string" + }, + "description": { + "type": "string" + }, + "direction": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "originalData": { + "additionalProperties": { + "type": "string" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "reference": { + "type": "string" + }, + "sequence": { + "type": "number" + } + }, + "required": [ + "sequence", + "date", + "description", + "amount", + "direction", + "currency" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "accountId" + ], + "type": "object" + }, + "type": "array" + }, + "categories": { + "items": { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "type": "array" + }, + "currency": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "declared": { + "items": { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "type": "array" + }, + "productId": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "productName": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "productId", + "productName", + "currency", + "accounts" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "products" + ], + "type": "object" + }, + "type": "array" +} - added
Output schema / properties / elapsedMsAdded value: +{ + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "pass": { + "type": "number" + }, + "total": { + "type": "number" + } + }, + "required": [ + "pass", + "total" + ], + "type": "object" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / estimateSecondsAdded value: +{ + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] +} - changed
Output schema / properties / extraction / additionalPropertiesPrevious value: -{}New value: +false - changed
Output schema / properties / gating / anyOfPrevious value: -[ - { - "additionalProperties": {}, - "properties": { - "accessMode": { - "enum": [ - "paid", - "free_processed" - ], - "type": "string" - }, - "gatedRecipe": { - "anyOf": [ - { - "enum": [ - "template-first", - "vlm-learning" - ], - "type": "string" - }, - { - "type": "null" - } - ] - }, - "hiddenTransactionPages": { - "type": "number" - }, - "previewMode": { - "type": "boolean" - }, - "previewPageLimit": { - "anyOf": [ - { - "type": "number" - }, - { - "type": "null" - } - ] - }, - "previewPages": { - "items": { - "type": "number" - }, - "type": "array" - }, - "previewTransactionCount": { - "type": "number" - }, - "processedPages": { - "type": "number" - }, - "requiresPlanUpgrade": { - "type": "boolean" - }, - "resultQuality": { - "enum": [ - "verified", - "partial", - "unverified" - ], - "type": "string" - }, - "totalPages": { - "type": "number" - }, - "totalTransactionCount": { - "type": "number" - }, - "unlocked": { - "type": "boolean" - } - }, - "required": [ - "previewMode", - "accessMode", - "previewPageLimit", - "previewPages", - "hiddenTransactionPages", - "processedPages", - "totalPages", - "totalTransactionCount", - "previewTransactionCount", - "unlocked", - "requiresPlanUpgrade", - "resultQuality", - "gatedRecipe" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "accessMode": { + "enum": [ + "paid", + "free_processed" + ], + "type": "string" + }, + "gatedRecipe": { + "anyOf": [ + { + "enum": [ + "template-first", + "vlm-learning" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "hiddenTransactionPages": { + "type": "number" + }, + "previewMode": { + "type": "boolean" + }, + "previewPageLimit": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "previewPages": { + "items": { + "type": "number" + }, + "type": "array" + }, + "previewTransactionCount": { + "type": "number" + }, + "processedPages": { + "type": "number" + }, + "requiresPlanUpgrade": { + "type": "boolean" + }, + "resultQuality": { + "enum": [ + "verified", + "partial", + "unverified" + ], + "type": "string" + }, + "totalPages": { + "type": "number" + }, + "totalTransactionCount": { + "type": "number" + }, + "unlocked": { + "type": "boolean" + } + }, + "required": [ + "previewMode", + "accessMode", + "previewPageLimit", + "previewPages", + "hiddenTransactionPages", + "processedPages", + "totalPages", + "totalTransactionCount", + "previewTransactionCount", + "unlocked", + "requiresPlanUpgrade", + "resultQuality", + "gatedRecipe" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / properties / pagination / additionalPropertiesPrevious value: -{}New value: +false - added
Output schema / properties / processingProgressAdded value: +{ + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "pagesProcessed": { + "type": "number" + }, + "pass": { + "additionalProperties": false, + "properties": { + "number": { + "type": "number" + }, + "startedAt": { + "type": "number" + } + }, + "required": [ + "number", + "startedAt" + ], + "type": "object" + }, + "totalPages": { + "type": "number" + } + }, + "required": [ + "pagesProcessed", + "totalPages" + ], + "type": "object" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / processingStageAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] +} - changed
Output schema / properties / results / items / additionalPropertiesPrevious value: -{}New value: +false - changed
Output schema / properties / warnings / items / additionalPropertiesPrevious value: -{}New value: +false
- Changed
evaluate_benchmark9 fields changed- added
Output schema / $defsAdded value: +{ + "__schema0": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "number" + }, + { + "type": "boolean" + }, + { + "type": "null" + }, + { + "items": { + "$ref": "#/$defs/__schema0" + }, + "type": "array" + }, + { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + } + ] + } +} - added
Output schema / properties / contentHashAdded value: +{ + "type": "string" +} - added
Output schema / properties / datasetVersionAdded value: +{ + "type": "string" +} - added
Output schema / properties / normalizedScore / additionalProperties / $refAdded value: +"#/$defs/__schema0" - removed
Output schema / properties / normalizedScore / propertiesRemoved value: -{} - added
Output schema / properties / normalizedScore / propertyNamesAdded value: +{ + "type": "string" +} - added
Output schema / properties / parsedScore / additionalProperties / $refAdded value: +"#/$defs/__schema0" - removed
Output schema / properties / parsedScore / propertiesRemoved value: -{} - added
Output schema / properties / parsedScore / propertyNamesAdded value: +{ + "type": "string" +}
- Changed
get_statement23 fields changed- added
Output schema / $defsAdded value: +{ + "__schema0": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "number" + }, + { + "type": "boolean" + }, + { + "type": "null" + }, + { + "items": { + "$ref": "#/$defs/__schema0" + }, + "type": "array" + }, + { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + } + ] + } +} - changed
Output schema / properties / columns / items / additionalPropertiesPrevious value: -{}New value: +false - added
Output schema / properties / completedAtAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / createdAtAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / document / properties / bankAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / document / properties / bankIdAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / document / properties / countryAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / document / properties / currencyAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / document / properties / documentTypeAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / document / properties / languagesAdded value: +{ + "anyOf": [ + { + "items": { + "type": "string" + }, + "type": "array" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / document / properties / pageCountAdded value: +{ + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / document / properties / statementDateAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / document / properties / statementPeriodAdded value: +{ + "additionalProperties": false, + "properties": { + "from": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "to": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "from", + "to" + ], + "type": "object" +} - added
Output schema / properties / document / properties / statementsAdded value: +{ + "items": { + "additionalProperties": {}, + "properties": { + "date": { + "type": "string" + }, + "period": { + "additionalProperties": false, + "properties": { + "from": { + "type": "string" + }, + "to": { + "type": "string" + } + }, + "required": [ + "from", + "to" + ], + "type": "object" + }, + "products": { + "items": { + "additionalProperties": {}, + "properties": { + "accounts": { + "items": { + "additionalProperties": false, + "properties": { + "accountHolderName": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "accountId": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "accountNumber": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "cardNumber": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "categories": { + "items": { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "type": "array" + }, + "currency": { + "type": "string" + }, + "declared": { + "items": { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "type": "array" + }, + "totals": { + "additionalProperties": false, + "properties": { + "closingBalance": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "openingBalance": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "totalCredits": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "totalDebits": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + } + }, + "type": "object" + }, + "transactions": { + "items": { + "additionalProperties": false, + "properties": { + "accountId": { + "type": "number" + }, + "amount": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "string" + } + ] + }, + "balance": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "string" + } + ] + }, + "category": { + "type": "string" + }, + "checkNumber": { + "type": "string" + }, + "currency": { + "type": "string" + }, + "date": { + "type": "string" + }, + "description": { + "type": "string" + }, + "direction": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "originalData": { + "additionalProperties": { + "type": "string" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "reference": { + "type": "string" + }, + "sequence": { + "type": "number" + } + }, + "required": [ + "sequence", + "date", + "description", + "amount", + "direction", + "currency" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "accountId" + ], + "type": "object" + }, + "type": "array" + }, + "categories": { + "items": { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "type": "array" + }, + "currency": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "declared": { + "items": { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "type": "array" + }, + "productId": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "productName": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "productId", + "productName", + "currency", + "accounts" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "products" + ], + "type": "object" + }, + "type": "array" +} - added
Output schema / properties / elapsedMsAdded value: +{ + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "pass": { + "type": "number" + }, + "total": { + "type": "number" + } + }, + "required": [ + "pass", + "total" + ], + "type": "object" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / estimateSecondsAdded value: +{ + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] +} - changed
Output schema / properties / extraction / additionalPropertiesPrevious value: -{}New value: +false - changed
Output schema / properties / gating / anyOfPrevious value: -[ - { - "additionalProperties": {}, - "properties": { - "accessMode": { - "enum": [ - "paid", - "free_processed" - ], - "type": "string" - }, - "gatedRecipe": { - "anyOf": [ - { - "enum": [ - "template-first", - "vlm-learning" - ], - "type": "string" - }, - { - "type": "null" - } - ] - }, - "hiddenTransactionPages": { - "type": "number" - }, - "previewMode": { - "type": "boolean" - }, - "previewPageLimit": { - "anyOf": [ - { - "type": "number" - }, - { - "type": "null" - } - ] - }, - "previewPages": { - "items": { - "type": "number" - }, - "type": "array" - }, - "previewTransactionCount": { - "type": "number" - }, - "processedPages": { - "type": "number" - }, - "requiresPlanUpgrade": { - "type": "boolean" - }, - "resultQuality": { - "enum": [ - "verified", - "partial", - "unverified" - ], - "type": "string" - }, - "totalPages": { - "type": "number" - }, - "totalTransactionCount": { - "type": "number" - }, - "unlocked": { - "type": "boolean" - } - }, - "required": [ - "previewMode", - "accessMode", - "previewPageLimit", - "previewPages", - "hiddenTransactionPages", - "processedPages", - "totalPages", - "totalTransactionCount", - "previewTransactionCount", - "unlocked", - "requiresPlanUpgrade", - "resultQuality", - "gatedRecipe" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "accessMode": { + "enum": [ + "paid", + "free_processed" + ], + "type": "string" + }, + "gatedRecipe": { + "anyOf": [ + { + "enum": [ + "template-first", + "vlm-learning" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "hiddenTransactionPages": { + "type": "number" + }, + "previewMode": { + "type": "boolean" + }, + "previewPageLimit": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "previewPages": { + "items": { + "type": "number" + }, + "type": "array" + }, + "previewTransactionCount": { + "type": "number" + }, + "processedPages": { + "type": "number" + }, + "requiresPlanUpgrade": { + "type": "boolean" + }, + "resultQuality": { + "enum": [ + "verified", + "partial", + "unverified" + ], + "type": "string" + }, + "totalPages": { + "type": "number" + }, + "totalTransactionCount": { + "type": "number" + }, + "unlocked": { + "type": "boolean" + } + }, + "required": [ + "previewMode", + "accessMode", + "previewPageLimit", + "previewPages", + "hiddenTransactionPages", + "processedPages", + "totalPages", + "totalTransactionCount", + "previewTransactionCount", + "unlocked", + "requiresPlanUpgrade", + "resultQuality", + "gatedRecipe" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / properties / pagination / additionalPropertiesPrevious value: -{}New value: +false - added
Output schema / properties / processingProgressAdded value: +{ + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "pagesProcessed": { + "type": "number" + }, + "pass": { + "additionalProperties": false, + "properties": { + "number": { + "type": "number" + }, + "startedAt": { + "type": "number" + } + }, + "required": [ + "number", + "startedAt" + ], + "type": "object" + }, + "totalPages": { + "type": "number" + } + }, + "required": [ + "pagesProcessed", + "totalPages" + ], + "type": "object" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / processingStageAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] +} - changed
Output schema / properties / results / items / additionalPropertiesPrevious value: -{}New value: +false - changed
Output schema / properties / warnings / items / additionalPropertiesPrevious value: -{}New value: +false
- Changed
group_by3 fields changed- added
Output schema / $defsAdded value: +{ + "__schema0": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "number" + }, + { + "type": "boolean" + }, + { + "type": "null" + }, + { + "items": { + "$ref": "#/$defs/__schema0" + }, + "type": "array" + }, + { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + } + ] + } +} - changed
Output schema / properties / result / anyOfPrevious value: -[ - { - "additionalProperties": {}, - "properties": {}, - "type": "object" - }, - { - "items": { - "additionalProperties": {}, - "properties": {}, - "type": "object" - }, - "type": "array" - } -]New value: +[ + { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + { + "items": { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "type": "array" + } +] - changed
Output schema / properties / scope / additionalPropertiesPrevious value: -{}New value: +false
- Changed
list_statements12 fields changed- added
Output schema / properties / documents / items / properties / bankAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / documents / items / properties / countryAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / documents / items / properties / currencyAdded value: +{ + "type": "string" +} - added
Output schema / properties / documents / items / properties / elapsedMsAdded value: +{ + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "pass": { + "type": "number" + }, + "total": { + "type": "number" + } + }, + "required": [ + "pass", + "total" + ], + "type": "object" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / documents / items / properties / errorAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / documents / items / properties / estimateSecondsAdded value: +{ + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / documents / items / properties / processingProgressAdded value: +{ + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "pagesProcessed": { + "type": "number" + }, + "pass": { + "additionalProperties": false, + "properties": { + "number": { + "type": "number" + }, + "startedAt": { + "type": "number" + } + }, + "required": [ + "number", + "startedAt" + ], + "type": "object" + }, + "totalPages": { + "type": "number" + } + }, + "required": [ + "pagesProcessed", + "totalPages" + ], + "type": "object" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / documents / items / properties / processingStageAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] +} - added
Output schema / properties / documents / items / properties / summaryAdded value: +{ + "type": "string" +} - added
Output schema / properties / documents / items / properties / transactionCountAdded value: +{ + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] +} - changed
Output schema / properties / documents / items / requiredPrevious value: -[ - "id", - "status", - "filename", - "pageCount", - "createdAt", - "completedAt" -]New value: +[ + "id", + "status" +] - changed
Output schema / properties / pagination / additionalPropertiesPrevious value: -{}New value: +false
- Changed
list_transactions1 field changed- changed
Output schema / properties / scope / additionalPropertiesPrevious value: -{}New value: +false
- Changed
list_transfers35 fields changed- changed
Output schema / properties / accountSuccessions / items / additionalPropertiesPrevious value: -{}New value: +false - added
Output schema / properties / accountSuccessions / items / properties / currencyAdded value: +{ + "type": "string" +} - added
Output schema / properties / accountSuccessions / items / properties / effectiveDateAdded value: +{ + "type": "string" +} - added
Output schema / properties / accountSuccessions / items / properties / predecessorAccountAdded value: +{ + "type": "string" +} - added
Output schema / properties / accountSuccessions / items / properties / predecessorDropAmountAdded value: +{ + "type": "number" +} - added
Output schema / properties / accountSuccessions / items / properties / provenanceAdded value: +{ + "const": "deterministic", + "type": "string" +} - added
Output schema / properties / accountSuccessions / items / properties / successorAccountsAdded value: +{ + "items": { + "type": "string" + }, + "type": "array" +} - added
Output schema / properties / accountSuccessions / items / properties / successorOpeningAmountAdded value: +{ + "type": "number" +} - added
Output schema / properties / accountSuccessions / items / requiredAdded value: +[ + "predecessorAccount", + "successorAccounts", + "currency", + "predecessorDropAmount", + "successorOpeningAmount", + "effectiveDate", + "provenance" +] - changed
Output schema / properties / ambiguous / items / additionalPropertiesPrevious value: -{}New value: +false - added
Output schema / properties / ambiguous / items / properties / amountAdded value: +{ + "type": "number" +} - added
Output schema / properties / ambiguous / items / properties / currencyAdded value: +{ + "type": "string" +} - added
Output schema / properties / ambiguous / items / properties / fromAccountAdded value: +{ + "type": "string" +} - added
Output schema / properties / ambiguous / items / properties / fromDateAdded value: +{ + "type": "string" +} - added
Output schema / properties / ambiguous / items / properties / fromTransactionIdAdded value: +{ + "type": "string" +} - added
Output schema / properties / ambiguous / items / properties / toAccountAdded value: +{ + "type": "string" +} - added
Output schema / properties / ambiguous / items / properties / toDateAdded value: +{ + "type": "string" +} - added
Output schema / properties / ambiguous / items / properties / toTransactionIdAdded value: +{ + "type": "string" +} - added
Output schema / properties / ambiguous / items / requiredAdded value: +[ + "fromAccount", + "toAccount", + "fromTransactionId", + "toTransactionId", + "amount", + "currency", + "fromDate", + "toDate" +] - changed
Output schema / properties / scope / additionalPropertiesPrevious value: -{}New value: +false - changed
Output schema / properties / transfers / items / additionalPropertiesPrevious value: -{}New value: +false - added
Output schema / properties / transfers / items / properties / amountAdded value: +{ + "type": "number" +} - added
Output schema / properties / transfers / items / properties / currencyAdded value: +{ + "type": "string" +} - added
Output schema / properties / transfers / items / properties / dateDeltaDaysAdded value: +{ + "type": "number" +} - added
Output schema / properties / transfers / items / properties / fromAccountAdded value: +{ + "type": "string" +} - added
Output schema / properties / transfers / items / properties / fromDateAdded value: +{ + "type": "string" +} - added
Output schema / properties / transfers / items / properties / provenanceAdded value: +{ + "enum": [ + "deterministic", + "judge" + ], + "type": "string" +} - added
Output schema / properties / transfers / items / properties / toAccountAdded value: +{ + "type": "string" +} - added
Output schema / properties / transfers / items / properties / toDateAdded value: +{ + "type": "string" +} - added
Output schema / properties / transfers / items / requiredAdded value: +[ + "fromAccount", + "toAccount", + "amount", + "currency", + "fromDate", + "toDate", + "dateDeltaDays", + "provenance" +] - changed
Output schema / properties / unmatched / additionalPropertiesPrevious value: -{}New value: +false - added
Output schema / properties / unmatched / properties / countAdded value: +{ + "type": "number" +} - added
Output schema / properties / unmatched / properties / floorAmountAdded value: +{ + "type": "number" +} - added
Output schema / properties / unmatched / properties / movementsAdded value: +{ + "items": { + "additionalProperties": false, + "properties": { + "account": { + "type": "string" + }, + "amount": { + "type": "number" + }, + "currency": { + "type": "string" + }, + "date": { + "type": "string" + }, + "description": { + "type": "string" + }, + "direction": { + "enum": [ + "credit", + "debit" + ], + "type": "string" + }, + "sourceDocument": { + "additionalProperties": false, + "properties": { + "contentHash": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "contentHash" + ], + "type": "object" + } + }, + "required": [ + "account", + "date", + "description", + "amount", + "currency", + "direction", + "sourceDocument" + ], + "type": "object" + }, + "type": "array" +} - added
Output schema / properties / unmatched / requiredAdded value: +[ + "floorAmount", + "count", + "movements" +]
- Changed
time_series3 fields changed- added
Output schema / $defsAdded value: +{ + "__schema0": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "number" + }, + { + "type": "boolean" + }, + { + "type": "null" + }, + { + "items": { + "$ref": "#/$defs/__schema0" + }, + "type": "array" + }, + { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + } + ] + } +} - changed
Output schema / properties / result / anyOfPrevious value: -[ - { - "additionalProperties": {}, - "properties": {}, - "type": "object" - }, - { - "items": { - "additionalProperties": {}, - "properties": {}, - "type": "object" - }, - "type": "array" - } -]New value: +[ + { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + { + "items": { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "type": "array" + } +] - changed
Output schema / properties / scope / additionalPropertiesPrevious value: -{}New value: +false
- Changed
top_n3 fields changed- added
Output schema / $defsAdded value: +{ + "__schema0": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "number" + }, + { + "type": "boolean" + }, + { + "type": "null" + }, + { + "items": { + "$ref": "#/$defs/__schema0" + }, + "type": "array" + }, + { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + } + ] + } +} - changed
Output schema / properties / result / anyOfPrevious value: -[ - { - "additionalProperties": {}, - "properties": {}, - "type": "object" - }, - { - "items": { - "additionalProperties": {}, - "properties": {}, - "type": "object" - }, - "type": "array" - } -]New value: +[ + { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + { + "items": { + "additionalProperties": { + "$ref": "#/$defs/__schema0" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "type": "array" + } +] - changed
Output schema / properties / scope / additionalPropertiesPrevious value: -{}New value: +false
16 tool updates
- Changed
aggregate21 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / properties / filter / descriptionAdded value: +"Subset of transactions to operate on. All fields are optional and combined with AND logic." - added
Input schema / properties / filter / properties / accounts / descriptionAdded value: +"Account number slugs to include." - added
Input schema / properties / filter / properties / amountMax / descriptionAdded value: +"Inclusive maximum absolute amount." - added
Input schema / properties / filter / properties / amountMin / descriptionAdded value: +"Inclusive minimum absolute amount." - added
Input schema / properties / filter / properties / category / descriptionAdded value: +"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"." - added
Input schema / properties / filter / properties / currency / descriptionAdded value: +"ISO 4217 currency code. E.g. \"USD\", \"HKD\"." - added
Input schema / properties / filter / properties / dateEnd / descriptionAdded value: +"ISO date (YYYY-MM-DD). Inclusive upper bound." - added
Input schema / properties / filter / properties / dateStart / descriptionAdded value: +"ISO date (YYYY-MM-DD). Inclusive lower bound." - added
Input schema / properties / filter / properties / direction / descriptionAdded value: +"Semantic direction." - added
Input schema / properties / filter / properties / merchant / descriptionAdded value: +"Substring match against description or counterparty (case-insensitive)." - added
Input schema / properties / filter / properties / text / descriptionAdded value: +"Whole-row text search over raw transaction fields (case-insensitive)." - added
Input schema / properties / metric / descriptionAdded value: +"Aggregation metric." - added
Input schema / properties / scope / descriptionAdded 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)." - added
Input schema / properties / scope / properties / accounts / descriptionAdded value: +"Account/product chips (kind + identityKey) to scope to. Empty = all accounts." - removed
Input schema / properties / scope / properties / accounts / items / anyOfRemoved 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" - } -] - added
Input schema / properties / scope / properties / accounts / items / oneOfAdded 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" + } +] - added
Input schema / properties / scope / properties / dateRange / descriptionAdded value: +"Bounds results to transactions within this date range. Omit for no date filter." - added
Input schema / properties / scope / properties / dateRange / properties / from / descriptionAdded value: +"Start of the date range (inclusive), YYYY-MM-DD." - added
Input schema / properties / scope / properties / dateRange / properties / to / descriptionAdded value: +"End of the date range (inclusive), YYYY-MM-DD." - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
categorize_statement3 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / properties / document_id / descriptionAdded value: +"Document ID (from convert_statement or list_statements)" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
compare32 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / properties / filterA / descriptionAdded value: +"Subset of transactions to operate on. All fields are optional and combined with AND logic." - added
Input schema / properties / filterA / properties / accounts / descriptionAdded value: +"Account number slugs to include." - added
Input schema / properties / filterA / properties / amountMax / descriptionAdded value: +"Inclusive maximum absolute amount." - added
Input schema / properties / filterA / properties / amountMin / descriptionAdded value: +"Inclusive minimum absolute amount." - added
Input schema / properties / filterA / properties / category / descriptionAdded value: +"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"." - added
Input schema / properties / filterA / properties / currency / descriptionAdded value: +"ISO 4217 currency code. E.g. \"USD\", \"HKD\"." - added
Input schema / properties / filterA / properties / dateEnd / descriptionAdded value: +"ISO date (YYYY-MM-DD). Inclusive upper bound." - added
Input schema / properties / filterA / properties / dateStart / descriptionAdded value: +"ISO date (YYYY-MM-DD). Inclusive lower bound." - added
Input schema / properties / filterA / properties / direction / descriptionAdded value: +"Semantic direction." - added
Input schema / properties / filterA / properties / merchant / descriptionAdded value: +"Substring match against description or counterparty (case-insensitive)." - added
Input schema / properties / filterA / properties / text / descriptionAdded value: +"Whole-row text search over raw transaction fields (case-insensitive)." - added
Input schema / properties / filterB / descriptionAdded value: +"Subset of transactions to operate on. All fields are optional and combined with AND logic." - added
Input schema / properties / filterB / properties / accounts / descriptionAdded value: +"Account number slugs to include." - added
Input schema / properties / filterB / properties / amountMax / descriptionAdded value: +"Inclusive maximum absolute amount." - added
Input schema / properties / filterB / properties / amountMin / descriptionAdded value: +"Inclusive minimum absolute amount." - added
Input schema / properties / filterB / properties / category / descriptionAdded value: +"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"." - added
Input schema / properties / filterB / properties / currency / descriptionAdded value: +"ISO 4217 currency code. E.g. \"USD\", \"HKD\"." - added
Input schema / properties / filterB / properties / dateEnd / descriptionAdded value: +"ISO date (YYYY-MM-DD). Inclusive upper bound." - added
Input schema / properties / filterB / properties / dateStart / descriptionAdded value: +"ISO date (YYYY-MM-DD). Inclusive lower bound." - added
Input schema / properties / filterB / properties / direction / descriptionAdded value: +"Semantic direction." - added
Input schema / properties / filterB / properties / merchant / descriptionAdded value: +"Substring match against description or counterparty (case-insensitive)." - added
Input schema / properties / filterB / properties / text / descriptionAdded value: +"Whole-row text search over raw transaction fields (case-insensitive)." - added
Input schema / properties / metric / descriptionAdded value: +"Metric for both groups." - added
Input schema / properties / scope / descriptionAdded 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)." - added
Input schema / properties / scope / properties / accounts / descriptionAdded value: +"Account/product chips (kind + identityKey) to scope to. Empty = all accounts." - removed
Input schema / properties / scope / properties / accounts / items / anyOfRemoved 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" - } -] - added
Input schema / properties / scope / properties / accounts / items / oneOfAdded 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" + } +] - added
Input schema / properties / scope / properties / dateRange / descriptionAdded value: +"Bounds results to transactions within this date range. Omit for no date filter." - added
Input schema / properties / scope / properties / dateRange / properties / from / descriptionAdded value: +"Start of the date range (inclusive), YYYY-MM-DD." - added
Input schema / properties / scope / properties / dateRange / properties / to / descriptionAdded value: +"End of the date range (inclusive), YYYY-MM-DD." - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
convert_statement13 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / properties / output_format / descriptionAdded value: +"Output format" - added
Input schema / properties / password / descriptionAdded value: +"Password for encrypted PDFs" - added
Input schema / properties / pdf / descriptionAdded value: +"Base64-encoded PDF content — last resort only; prefer pdf_file for an attachment or pdf_url for a link" - added
Input schema / properties / pdf_file / descriptionAdded value: +"An attached PDF (populated automatically by ChatGPT — do not construct this yourself)." - added
Input schema / properties / pdf_file / properties / download_url / descriptionAdded value: +"Signed URL ChatGPT provides to fetch the attached PDF's bytes." - added
Input schema / properties / pdf_file / properties / file_id / descriptionAdded value: +"ChatGPT's identifier for the attached file." - added
Input schema / properties / pdf_file / properties / file_name / descriptionAdded value: +"Original filename of the attached file, when ChatGPT provides one." - added
Input schema / properties / pdf_file / properties / mime_type / descriptionAdded value: +"MIME type of the attached file, when ChatGPT provides one." - added
Input schema / properties / pdf_url / descriptionAdded value: +"HTTPS URL to fetch the PDF from" - added
Input schema / properties / upload_id / descriptionAdded 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)." - added
Input schema / properties / upload_ids / descriptionAdded 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." - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
dismiss_statement3 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / properties / document_id / descriptionAdded value: +"Document ID from list_statements, convert_statement, or get_statement" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
evaluate_benchmark18 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / properties / accounts / descriptionAdded value: +"Optional account roster for multi-account statements. Each transaction references one via accountId." - added
Input schema / properties / accounts / items / properties / accountNumber / descriptionAdded value: +"Verbatim printed account number — never normalized by the submitter." - added
Input schema / properties / accounts / items / properties / currency / descriptionAdded value: +"ISO 4217 currency code." - added
Input schema / properties / accounts / items / properties / id / descriptionAdded value: +"Submission-internal handle, referenced by transactions[].accountId." - added
Input schema / properties / accounts / items / properties / name / descriptionAdded value: +"Verbatim printed account label." - added
Input schema / properties / content_hash / descriptionAdded value: +"SHA-256 hex digest of the PDF. Use statement_id instead if you know it." - added
Input schema / properties / statement_id / descriptionAdded value: +"Benchmark statement ID (e.g. \"bsb-001\"). Preferred over content_hash." - added
Input schema / properties / transactions / descriptionAdded value: +"Parsed transactions (1-2000)" - added
Input schema / properties / transactions / items / properties / accountId / descriptionAdded value: +"References accounts[].id — the account this transaction belongs to. Omit for single-account statements." - added
Input schema / properties / transactions / items / properties / amount / descriptionAdded value: +"Transaction amount. Negative = debit, positive = credit (or use direction)." - added
Input schema / properties / transactions / items / properties / balance / descriptionAdded value: +"Running balance after this transaction, if known." - added
Input schema / properties / transactions / items / properties / currency / descriptionAdded value: +"ISO 4217 currency code for this transaction, if known." - added
Input schema / properties / transactions / items / properties / date / descriptionAdded value: +"ISO 8601 date (YYYY-MM-DD)" - added
Input schema / properties / transactions / items / properties / description / descriptionAdded value: +"Transaction description as printed on the statement." - added
Input schema / properties / transactions / items / properties / direction / descriptionAdded value: +"Explicit direction. If omitted, inferred from amount sign." - added
Input schema / properties / transactions / items / properties / originalData / descriptionAdded 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." - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
get_credits2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
get_statement7 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / properties / data_mode / descriptionAdded 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." - added
Input schema / properties / document_id / descriptionAdded value: +"Document ID (from convert_statement or list_statements)" - added
Input schema / properties / limit / descriptionAdded value: +"output_format \"json\" only. Max transactions to return (default 500, capped at 2000, or 500 with data_mode \"original\")." - added
Input schema / properties / offset / descriptionAdded value: +"output_format \"json\" only. Number of transactions to skip. Omit to start from the beginning." - added
Input schema / properties / output_format / descriptionAdded value: +"Output format" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
group_by22 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / properties / dimension / descriptionAdded value: +"Grouping dimension." - added
Input schema / properties / filter / descriptionAdded value: +"Subset of transactions to operate on. All fields are optional and combined with AND logic." - added
Input schema / properties / filter / properties / accounts / descriptionAdded value: +"Account number slugs to include." - added
Input schema / properties / filter / properties / amountMax / descriptionAdded value: +"Inclusive maximum absolute amount." - added
Input schema / properties / filter / properties / amountMin / descriptionAdded value: +"Inclusive minimum absolute amount." - added
Input schema / properties / filter / properties / category / descriptionAdded value: +"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"." - added
Input schema / properties / filter / properties / currency / descriptionAdded value: +"ISO 4217 currency code. E.g. \"USD\", \"HKD\"." - added
Input schema / properties / filter / properties / dateEnd / descriptionAdded value: +"ISO date (YYYY-MM-DD). Inclusive upper bound." - added
Input schema / properties / filter / properties / dateStart / descriptionAdded value: +"ISO date (YYYY-MM-DD). Inclusive lower bound." - added
Input schema / properties / filter / properties / direction / descriptionAdded value: +"Semantic direction." - added
Input schema / properties / filter / properties / merchant / descriptionAdded value: +"Substring match against description or counterparty (case-insensitive)." - added
Input schema / properties / filter / properties / text / descriptionAdded value: +"Whole-row text search over raw transaction fields (case-insensitive)." - added
Input schema / properties / metric / descriptionAdded value: +"Metric per group." - added
Input schema / properties / scope / descriptionAdded 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)." - added
Input schema / properties / scope / properties / accounts / descriptionAdded value: +"Account/product chips (kind + identityKey) to scope to. Empty = all accounts." - removed
Input schema / properties / scope / properties / accounts / items / anyOfRemoved 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" - } -] - added
Input schema / properties / scope / properties / accounts / items / oneOfAdded 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" + } +] - added
Input schema / properties / scope / properties / dateRange / descriptionAdded value: +"Bounds results to transactions within this date range. Omit for no date filter." - added
Input schema / properties / scope / properties / dateRange / properties / from / descriptionAdded value: +"Start of the date range (inclusive), YYYY-MM-DD." - added
Input schema / properties / scope / properties / dateRange / properties / to / descriptionAdded value: +"End of the date range (inclusive), YYYY-MM-DD." - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
list_statements5 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / properties / limit / descriptionAdded value: +"Max results (1-100)" - added
Input schema / properties / offset / descriptionAdded value: +"Pagination offset" - added
Input schema / properties / status / descriptionAdded value: +"Filter by status" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
list_transactions23 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / properties / filter / descriptionAdded value: +"Subset of transactions to operate on. All fields are optional and combined with AND logic." - added
Input schema / properties / filter / properties / accounts / descriptionAdded value: +"Account number slugs to include." - added
Input schema / properties / filter / properties / amountMax / descriptionAdded value: +"Inclusive maximum absolute amount." - added
Input schema / properties / filter / properties / amountMin / descriptionAdded value: +"Inclusive minimum absolute amount." - added
Input schema / properties / filter / properties / category / descriptionAdded value: +"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"." - added
Input schema / properties / filter / properties / currency / descriptionAdded value: +"ISO 4217 currency code. E.g. \"USD\", \"HKD\"." - added
Input schema / properties / filter / properties / dateEnd / descriptionAdded value: +"ISO date (YYYY-MM-DD). Inclusive upper bound." - added
Input schema / properties / filter / properties / dateStart / descriptionAdded value: +"ISO date (YYYY-MM-DD). Inclusive lower bound." - added
Input schema / properties / filter / properties / direction / descriptionAdded value: +"Semantic direction." - added
Input schema / properties / filter / properties / merchant / descriptionAdded value: +"Substring match against description or counterparty (case-insensitive)." - added
Input schema / properties / filter / properties / text / descriptionAdded value: +"Whole-row text search over raw transaction fields (case-insensitive)." - added
Input schema / properties / limit / descriptionAdded value: +"Maximum rows to return. Default 20, max 50." - added
Input schema / properties / order / descriptionAdded value: +"Sort direction. Default \"desc\" (largest amount / most recent date first). Only meaningful with sort_by." - added
Input schema / properties / scope / descriptionAdded 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)." - added
Input schema / properties / scope / properties / accounts / descriptionAdded value: +"Account/product chips (kind + identityKey) to scope to. Empty = all accounts." - removed
Input schema / properties / scope / properties / accounts / items / anyOfRemoved 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" - } -] - added
Input schema / properties / scope / properties / accounts / items / oneOfAdded 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" + } +] - added
Input schema / properties / scope / properties / dateRange / descriptionAdded value: +"Bounds results to transactions within this date range. Omit for no date filter." - added
Input schema / properties / scope / properties / dateRange / properties / from / descriptionAdded value: +"Start of the date range (inclusive), YYYY-MM-DD." - added
Input schema / properties / scope / properties / dateRange / properties / to / descriptionAdded value: +"End of the date range (inclusive), YYYY-MM-DD." - added
Input schema / properties / sort_by / descriptionAdded 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)." - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
list_transfers10 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / properties / amountMin / descriptionAdded 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." - added
Input schema / properties / scope / descriptionAdded 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)." - added
Input schema / properties / scope / properties / accounts / descriptionAdded value: +"Account/product chips (kind + identityKey) to scope to. Empty = all accounts." - removed
Input schema / properties / scope / properties / accounts / items / anyOfRemoved 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" - } -] - added
Input schema / properties / scope / properties / accounts / items / oneOfAdded 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" + } +] - added
Input schema / properties / scope / properties / dateRange / descriptionAdded value: +"Bounds results to transactions within this date range. Omit for no date filter." - added
Input schema / properties / scope / properties / dateRange / properties / from / descriptionAdded value: +"Start of the date range (inclusive), YYYY-MM-DD." - added
Input schema / properties / scope / properties / dateRange / properties / to / descriptionAdded value: +"End of the date range (inclusive), YYYY-MM-DD." - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
rate_statement9 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / properties / document_id / descriptionAdded value: +"Document ID (from convert_statement or list_statements)" - added
Input schema / properties / export_format / descriptionAdded value: +"Which output format you exported this conversion to (csv, xlsx, qbo, or xero)." - added
Input schema / properties / feedback / descriptionAdded value: +"Free-text feedback. Only accepted when rating is 3 or below." - added
Input schema / properties / feedback_categories / descriptionAdded value: +"Structured feedback categories. Only accepted when rating is 3 or below." - added
Input schema / properties / rating / descriptionAdded value: +"1-5 star rating for this conversion" - added
Input schema / properties / use_case / descriptionAdded value: +"Tags describing what you use the converted data for." - added
Input schema / properties / use_case_other / descriptionAdded value: +"Free-text use case, for when \"other\" is among the use_case tags." - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
request_upload3 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / properties / count / descriptionAdded 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." - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
time_series22 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / properties / bucket / descriptionAdded value: +"Bucket size." - added
Input schema / properties / filter / descriptionAdded value: +"Subset of transactions to operate on. All fields are optional and combined with AND logic." - added
Input schema / properties / filter / properties / accounts / descriptionAdded value: +"Account number slugs to include." - added
Input schema / properties / filter / properties / amountMax / descriptionAdded value: +"Inclusive maximum absolute amount." - added
Input schema / properties / filter / properties / amountMin / descriptionAdded value: +"Inclusive minimum absolute amount." - added
Input schema / properties / filter / properties / category / descriptionAdded value: +"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"." - added
Input schema / properties / filter / properties / currency / descriptionAdded value: +"ISO 4217 currency code. E.g. \"USD\", \"HKD\"." - added
Input schema / properties / filter / properties / dateEnd / descriptionAdded value: +"ISO date (YYYY-MM-DD). Inclusive upper bound." - added
Input schema / properties / filter / properties / dateStart / descriptionAdded value: +"ISO date (YYYY-MM-DD). Inclusive lower bound." - added
Input schema / properties / filter / properties / direction / descriptionAdded value: +"Semantic direction." - added
Input schema / properties / filter / properties / merchant / descriptionAdded value: +"Substring match against description or counterparty (case-insensitive)." - added
Input schema / properties / filter / properties / text / descriptionAdded value: +"Whole-row text search over raw transaction fields (case-insensitive)." - added
Input schema / properties / metric / descriptionAdded value: +"Metric per bucket." - added
Input schema / properties / scope / descriptionAdded 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)." - added
Input schema / properties / scope / properties / accounts / descriptionAdded value: +"Account/product chips (kind + identityKey) to scope to. Empty = all accounts." - removed
Input schema / properties / scope / properties / accounts / items / anyOfRemoved 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" - } -] - added
Input schema / properties / scope / properties / accounts / items / oneOfAdded 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" + } +] - added
Input schema / properties / scope / properties / dateRange / descriptionAdded value: +"Bounds results to transactions within this date range. Omit for no date filter." - added
Input schema / properties / scope / properties / dateRange / properties / from / descriptionAdded value: +"Start of the date range (inclusive), YYYY-MM-DD." - added
Input schema / properties / scope / properties / dateRange / properties / to / descriptionAdded value: +"End of the date range (inclusive), YYYY-MM-DD." - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
top_n23 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / properties / dimension / descriptionAdded value: +"Grouping dimension." - added
Input schema / properties / filter / descriptionAdded value: +"Subset of transactions to operate on. All fields are optional and combined with AND logic." - added
Input schema / properties / filter / properties / accounts / descriptionAdded value: +"Account number slugs to include." - added
Input schema / properties / filter / properties / amountMax / descriptionAdded value: +"Inclusive maximum absolute amount." - added
Input schema / properties / filter / properties / amountMin / descriptionAdded value: +"Inclusive minimum absolute amount." - added
Input schema / properties / filter / properties / category / descriptionAdded value: +"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"." - added
Input schema / properties / filter / properties / currency / descriptionAdded value: +"ISO 4217 currency code. E.g. \"USD\", \"HKD\"." - added
Input schema / properties / filter / properties / dateEnd / descriptionAdded value: +"ISO date (YYYY-MM-DD). Inclusive upper bound." - added
Input schema / properties / filter / properties / dateStart / descriptionAdded value: +"ISO date (YYYY-MM-DD). Inclusive lower bound." - added
Input schema / properties / filter / properties / direction / descriptionAdded value: +"Semantic direction." - added
Input schema / properties / filter / properties / merchant / descriptionAdded value: +"Substring match against description or counterparty (case-insensitive)." - added
Input schema / properties / filter / properties / text / descriptionAdded value: +"Whole-row text search over raw transaction fields (case-insensitive)." - added
Input schema / properties / metric / descriptionAdded value: +"Metric to rank by." - added
Input schema / properties / n / descriptionAdded value: +"Number of top groups to return." - added
Input schema / properties / scope / descriptionAdded 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)." - added
Input schema / properties / scope / properties / accounts / descriptionAdded value: +"Account/product chips (kind + identityKey) to scope to. Empty = all accounts." - removed
Input schema / properties / scope / properties / accounts / items / anyOfRemoved 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" - } -] - added
Input schema / properties / scope / properties / accounts / items / oneOfAdded 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" + } +] - added
Input schema / properties / scope / properties / dateRange / descriptionAdded value: +"Bounds results to transactions within this date range. Omit for no date filter." - added
Input schema / properties / scope / properties / dateRange / properties / from / descriptionAdded value: +"Start of the date range (inclusive), YYYY-MM-DD." - added
Input schema / properties / scope / properties / dateRange / properties / to / descriptionAdded value: +"End of the date range (inclusive), YYYY-MM-DD." - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
1 tool update
- Changed
list_statements2 fields changed- added
Output schema / properties / documents / items / properties / completedAtAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] +} - changed
Output schema / properties / documents / items / requiredPrevious value: -[ - "id", - "status", - "filename", - "pageCount", - "createdAt" -]New value: +[ + "id", + "status", + "filename", + "pageCount", + "createdAt", + "completedAt" +]
1 tool update
- Added
dismiss_statement
1 tool update
- Changed
list_transactions2 fields changed- added
Input schema / properties / orderAdded value: +{ + "enum": [ + "asc", + "desc" + ], + "type": "string" +} - added
Input schema / properties / sort_byAdded value: +{ + "enum": [ + "amount", + "date" + ], + "type": "string" +}
14 tool updates
- Changed
aggregate19 fields changed- removed
Input schema / properties / filter / descriptionRemoved value: -"Subset of transactions to operate on. All fields are optional and combined with AND logic." - removed
Input schema / properties / filter / properties / accounts / descriptionRemoved value: -"Account number slugs to include." - removed
Input schema / properties / filter / properties / amountMax / descriptionRemoved value: -"Inclusive maximum absolute amount." - removed
Input schema / properties / filter / properties / amountMin / descriptionRemoved value: -"Inclusive minimum absolute amount." - removed
Input schema / properties / filter / properties / category / descriptionRemoved value: -"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"." - removed
Input schema / properties / filter / properties / currency / descriptionRemoved value: -"ISO 4217 currency code. E.g. \"USD\", \"HKD\"." - removed
Input schema / properties / filter / properties / dateEnd / descriptionRemoved value: -"ISO date (YYYY-MM-DD). Inclusive upper bound." - removed
Input schema / properties / filter / properties / dateStart / descriptionRemoved value: -"ISO date (YYYY-MM-DD). Inclusive lower bound." - removed
Input schema / properties / filter / properties / direction / descriptionRemoved value: -"Semantic direction." - removed
Input schema / properties / filter / properties / merchant / descriptionRemoved value: -"Substring match against description or counterparty (case-insensitive)." - removed
Input schema / properties / filter / properties / text / descriptionRemoved value: -"Whole-row text search over raw transaction fields (case-insensitive)." - removed
Input schema / properties / metric / descriptionRemoved value: -"Aggregation metric." - removed
Input schema / properties / scope / descriptionRemoved 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)." - removed
Input schema / properties / scope / properties / accounts / descriptionRemoved value: -"Account/product chips (kind + identityKey) to scope to. Empty = all accounts." - added
Input schema / properties / scope / properties / accounts / items / anyOfAdded 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" + } +] - removed
Input schema / properties / scope / properties / accounts / items / oneOfRemoved 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" - } -] - removed
Input schema / properties / scope / properties / dateRange / descriptionRemoved value: -"Bounds results to transactions within this date range. Omit for no date filter." - removed
Input schema / properties / scope / properties / dateRange / properties / from / descriptionRemoved value: -"Start of the date range (inclusive), YYYY-MM-DD." - removed
Input schema / properties / scope / properties / dateRange / properties / to / descriptionRemoved value: -"End of the date range (inclusive), YYYY-MM-DD."
- Changed
categorize_statement1 field changed- removed
Input schema / properties / document_id / descriptionRemoved value: -"Document ID (from convert_statement or list_statements)"
- Changed
compare30 fields changed- removed
Input schema / properties / filterA / descriptionRemoved value: -"Subset of transactions to operate on. All fields are optional and combined with AND logic." - removed
Input schema / properties / filterA / properties / accounts / descriptionRemoved value: -"Account number slugs to include." - removed
Input schema / properties / filterA / properties / amountMax / descriptionRemoved value: -"Inclusive maximum absolute amount." - removed
Input schema / properties / filterA / properties / amountMin / descriptionRemoved value: -"Inclusive minimum absolute amount." - removed
Input schema / properties / filterA / properties / category / descriptionRemoved value: -"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"." - removed
Input schema / properties / filterA / properties / currency / descriptionRemoved value: -"ISO 4217 currency code. E.g. \"USD\", \"HKD\"." - removed
Input schema / properties / filterA / properties / dateEnd / descriptionRemoved value: -"ISO date (YYYY-MM-DD). Inclusive upper bound." - removed
Input schema / properties / filterA / properties / dateStart / descriptionRemoved value: -"ISO date (YYYY-MM-DD). Inclusive lower bound." - removed
Input schema / properties / filterA / properties / direction / descriptionRemoved value: -"Semantic direction." - removed
Input schema / properties / filterA / properties / merchant / descriptionRemoved value: -"Substring match against description or counterparty (case-insensitive)." - removed
Input schema / properties / filterA / properties / text / descriptionRemoved value: -"Whole-row text search over raw transaction fields (case-insensitive)." - removed
Input schema / properties / filterB / descriptionRemoved value: -"Subset of transactions to operate on. All fields are optional and combined with AND logic." - removed
Input schema / properties / filterB / properties / accounts / descriptionRemoved value: -"Account number slugs to include." - removed
Input schema / properties / filterB / properties / amountMax / descriptionRemoved value: -"Inclusive maximum absolute amount." - removed
Input schema / properties / filterB / properties / amountMin / descriptionRemoved value: -"Inclusive minimum absolute amount." - removed
Input schema / properties / filterB / properties / category / descriptionRemoved value: -"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"." - removed
Input schema / properties / filterB / properties / currency / descriptionRemoved value: -"ISO 4217 currency code. E.g. \"USD\", \"HKD\"." - removed
Input schema / properties / filterB / properties / dateEnd / descriptionRemoved value: -"ISO date (YYYY-MM-DD). Inclusive upper bound." - removed
Input schema / properties / filterB / properties / dateStart / descriptionRemoved value: -"ISO date (YYYY-MM-DD). Inclusive lower bound." - removed
Input schema / properties / filterB / properties / direction / descriptionRemoved value: -"Semantic direction." - removed
Input schema / properties / filterB / properties / merchant / descriptionRemoved value: -"Substring match against description or counterparty (case-insensitive)." - removed
Input schema / properties / filterB / properties / text / descriptionRemoved value: -"Whole-row text search over raw transaction fields (case-insensitive)." - removed
Input schema / properties / metric / descriptionRemoved value: -"Metric for both groups." - removed
Input schema / properties / scope / descriptionRemoved 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)." - removed
Input schema / properties / scope / properties / accounts / descriptionRemoved value: -"Account/product chips (kind + identityKey) to scope to. Empty = all accounts." - added
Input schema / properties / scope / properties / accounts / items / anyOfAdded 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" + } +] - removed
Input schema / properties / scope / properties / accounts / items / oneOfRemoved 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" - } -] - removed
Input schema / properties / scope / properties / dateRange / descriptionRemoved value: -"Bounds results to transactions within this date range. Omit for no date filter." - removed
Input schema / properties / scope / properties / dateRange / properties / from / descriptionRemoved value: -"Start of the date range (inclusive), YYYY-MM-DD." - removed
Input schema / properties / scope / properties / dateRange / properties / to / descriptionRemoved value: -"End of the date range (inclusive), YYYY-MM-DD."
- Changed
convert_statement11 fields changed- removed
Input schema / properties / output_format / descriptionRemoved value: -"Output format" - removed
Input schema / properties / password / descriptionRemoved value: -"Password for encrypted PDFs" - removed
Input schema / properties / pdf / descriptionRemoved value: -"Base64-encoded PDF content — last resort only; prefer pdf_file for an attachment or pdf_url for a link" - removed
Input schema / properties / pdf_file / descriptionRemoved value: -"An attached PDF (populated automatically by ChatGPT — do not construct this yourself)." - removed
Input schema / properties / pdf_file / properties / download_url / descriptionRemoved value: -"Signed URL ChatGPT provides to fetch the attached PDF's bytes." - removed
Input schema / properties / pdf_file / properties / file_id / descriptionRemoved value: -"ChatGPT's identifier for the attached file." - removed
Input schema / properties / pdf_file / properties / file_name / descriptionRemoved value: -"Original filename of the attached file, when ChatGPT provides one." - removed
Input schema / properties / pdf_file / properties / mime_type / descriptionRemoved value: -"MIME type of the attached file, when ChatGPT provides one." - removed
Input schema / properties / pdf_url / descriptionRemoved value: -"HTTPS URL to fetch the PDF from" - removed
Input schema / properties / upload_id / descriptionRemoved 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)." - removed
Input schema / properties / upload_ids / descriptionRemoved 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."
- Changed
evaluate_benchmark16 fields changed- removed
Input schema / properties / accounts / descriptionRemoved value: -"Optional account roster for multi-account statements. Each transaction references one via accountId." - removed
Input schema / properties / accounts / items / properties / accountNumber / descriptionRemoved value: -"Verbatim printed account number — never normalized by the submitter." - removed
Input schema / properties / accounts / items / properties / currency / descriptionRemoved value: -"ISO 4217 currency code." - removed
Input schema / properties / accounts / items / properties / id / descriptionRemoved value: -"Submission-internal handle, referenced by transactions[].accountId." - removed
Input schema / properties / accounts / items / properties / name / descriptionRemoved value: -"Verbatim printed account label." - removed
Input schema / properties / content_hash / descriptionRemoved value: -"SHA-256 hex digest of the PDF. Use statement_id instead if you know it." - removed
Input schema / properties / statement_id / descriptionRemoved value: -"Benchmark statement ID (e.g. \"bsb-001\"). Preferred over content_hash." - removed
Input schema / properties / transactions / descriptionRemoved value: -"Parsed transactions (1-2000)" - removed
Input schema / properties / transactions / items / properties / accountId / descriptionRemoved value: -"References accounts[].id — the account this transaction belongs to. Omit for single-account statements." - removed
Input schema / properties / transactions / items / properties / amount / descriptionRemoved value: -"Transaction amount. Negative = debit, positive = credit (or use direction)." - removed
Input schema / properties / transactions / items / properties / balance / descriptionRemoved value: -"Running balance after this transaction, if known." - removed
Input schema / properties / transactions / items / properties / currency / descriptionRemoved value: -"ISO 4217 currency code for this transaction, if known." - removed
Input schema / properties / transactions / items / properties / date / descriptionRemoved value: -"ISO 8601 date (YYYY-MM-DD)" - removed
Input schema / properties / transactions / items / properties / description / descriptionRemoved value: -"Transaction description as printed on the statement." - removed
Input schema / properties / transactions / items / properties / direction / descriptionRemoved value: -"Explicit direction. If omitted, inferred from amount sign." - removed
Input schema / properties / transactions / items / properties / originalData / descriptionRemoved 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."
- Changed
get_statement5 fields changed- removed
Input schema / properties / data_mode / descriptionRemoved 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." - removed
Input schema / properties / document_id / descriptionRemoved value: -"Document ID (from convert_statement or list_statements)" - removed
Input schema / properties / limit / descriptionRemoved value: -"output_format \"json\" only. Max transactions to return (default 500, capped at 2000, or 500 with data_mode \"original\")." - removed
Input schema / properties / offset / descriptionRemoved value: -"output_format \"json\" only. Number of transactions to skip. Omit to start from the beginning." - removed
Input schema / properties / output_format / descriptionRemoved value: -"Output format"
- Changed
group_by20 fields changed- removed
Input schema / properties / dimension / descriptionRemoved value: -"Grouping dimension." - removed
Input schema / properties / filter / descriptionRemoved value: -"Subset of transactions to operate on. All fields are optional and combined with AND logic." - removed
Input schema / properties / filter / properties / accounts / descriptionRemoved value: -"Account number slugs to include." - removed
Input schema / properties / filter / properties / amountMax / descriptionRemoved value: -"Inclusive maximum absolute amount." - removed
Input schema / properties / filter / properties / amountMin / descriptionRemoved value: -"Inclusive minimum absolute amount." - removed
Input schema / properties / filter / properties / category / descriptionRemoved value: -"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"." - removed
Input schema / properties / filter / properties / currency / descriptionRemoved value: -"ISO 4217 currency code. E.g. \"USD\", \"HKD\"." - removed
Input schema / properties / filter / properties / dateEnd / descriptionRemoved value: -"ISO date (YYYY-MM-DD). Inclusive upper bound." - removed
Input schema / properties / filter / properties / dateStart / descriptionRemoved value: -"ISO date (YYYY-MM-DD). Inclusive lower bound." - removed
Input schema / properties / filter / properties / direction / descriptionRemoved value: -"Semantic direction." - removed
Input schema / properties / filter / properties / merchant / descriptionRemoved value: -"Substring match against description or counterparty (case-insensitive)." - removed
Input schema / properties / filter / properties / text / descriptionRemoved value: -"Whole-row text search over raw transaction fields (case-insensitive)." - removed
Input schema / properties / metric / descriptionRemoved value: -"Metric per group." - removed
Input schema / properties / scope / descriptionRemoved 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)." - removed
Input schema / properties / scope / properties / accounts / descriptionRemoved value: -"Account/product chips (kind + identityKey) to scope to. Empty = all accounts." - added
Input schema / properties / scope / properties / accounts / items / anyOfAdded 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" + } +] - removed
Input schema / properties / scope / properties / accounts / items / oneOfRemoved 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" - } -] - removed
Input schema / properties / scope / properties / dateRange / descriptionRemoved value: -"Bounds results to transactions within this date range. Omit for no date filter." - removed
Input schema / properties / scope / properties / dateRange / properties / from / descriptionRemoved value: -"Start of the date range (inclusive), YYYY-MM-DD." - removed
Input schema / properties / scope / properties / dateRange / properties / to / descriptionRemoved value: -"End of the date range (inclusive), YYYY-MM-DD."
- Changed
list_statements3 fields changed- removed
Input schema / properties / limit / descriptionRemoved value: -"Max results (1-100)" - removed
Input schema / properties / offset / descriptionRemoved value: -"Pagination offset" - removed
Input schema / properties / status / descriptionRemoved value: -"Filter by status"
- Changed
list_transactions19 fields changed- removed
Input schema / properties / filter / descriptionRemoved value: -"Subset of transactions to operate on. All fields are optional and combined with AND logic." - removed
Input schema / properties / filter / properties / accounts / descriptionRemoved value: -"Account number slugs to include." - removed
Input schema / properties / filter / properties / amountMax / descriptionRemoved value: -"Inclusive maximum absolute amount." - removed
Input schema / properties / filter / properties / amountMin / descriptionRemoved value: -"Inclusive minimum absolute amount." - removed
Input schema / properties / filter / properties / category / descriptionRemoved value: -"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"." - removed
Input schema / properties / filter / properties / currency / descriptionRemoved value: -"ISO 4217 currency code. E.g. \"USD\", \"HKD\"." - removed
Input schema / properties / filter / properties / dateEnd / descriptionRemoved value: -"ISO date (YYYY-MM-DD). Inclusive upper bound." - removed
Input schema / properties / filter / properties / dateStart / descriptionRemoved value: -"ISO date (YYYY-MM-DD). Inclusive lower bound." - removed
Input schema / properties / filter / properties / direction / descriptionRemoved value: -"Semantic direction." - removed
Input schema / properties / filter / properties / merchant / descriptionRemoved value: -"Substring match against description or counterparty (case-insensitive)." - removed
Input schema / properties / filter / properties / text / descriptionRemoved value: -"Whole-row text search over raw transaction fields (case-insensitive)." - removed
Input schema / properties / limit / descriptionRemoved value: -"Maximum rows to return. Default 20, max 50." - removed
Input schema / properties / scope / descriptionRemoved 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)." - removed
Input schema / properties / scope / properties / accounts / descriptionRemoved value: -"Account/product chips (kind + identityKey) to scope to. Empty = all accounts." - added
Input schema / properties / scope / properties / accounts / items / anyOfAdded 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" + } +] - removed
Input schema / properties / scope / properties / accounts / items / oneOfRemoved 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" - } -] - removed
Input schema / properties / scope / properties / dateRange / descriptionRemoved value: -"Bounds results to transactions within this date range. Omit for no date filter." - removed
Input schema / properties / scope / properties / dateRange / properties / from / descriptionRemoved value: -"Start of the date range (inclusive), YYYY-MM-DD." - removed
Input schema / properties / scope / properties / dateRange / properties / to / descriptionRemoved value: -"End of the date range (inclusive), YYYY-MM-DD."
- Changed
list_transfers8 fields changed- removed
Input schema / properties / amountMin / descriptionRemoved 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." - removed
Input schema / properties / scope / descriptionRemoved 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)." - removed
Input schema / properties / scope / properties / accounts / descriptionRemoved value: -"Account/product chips (kind + identityKey) to scope to. Empty = all accounts." - added
Input schema / properties / scope / properties / accounts / items / anyOfAdded 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" + } +] - removed
Input schema / properties / scope / properties / accounts / items / oneOfRemoved 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" - } -] - removed
Input schema / properties / scope / properties / dateRange / descriptionRemoved value: -"Bounds results to transactions within this date range. Omit for no date filter." - removed
Input schema / properties / scope / properties / dateRange / properties / from / descriptionRemoved value: -"Start of the date range (inclusive), YYYY-MM-DD." - removed
Input schema / properties / scope / properties / dateRange / properties / to / descriptionRemoved value: -"End of the date range (inclusive), YYYY-MM-DD."
- Changed
rate_statement7 fields changed- removed
Input schema / properties / document_id / descriptionRemoved value: -"Document ID (from convert_statement or list_statements)" - removed
Input schema / properties / export_format / descriptionRemoved value: -"Which output format you exported this conversion to (csv, xlsx, qbo, or xero)." - removed
Input schema / properties / feedback / descriptionRemoved value: -"Free-text feedback. Only accepted when rating is 3 or below." - removed
Input schema / properties / feedback_categories / descriptionRemoved value: -"Structured feedback categories. Only accepted when rating is 3 or below." - removed
Input schema / properties / rating / descriptionRemoved value: -"1-5 star rating for this conversion" - removed
Input schema / properties / use_case / descriptionRemoved value: -"Tags describing what you use the converted data for." - removed
Input schema / properties / use_case_other / descriptionRemoved value: -"Free-text use case, for when \"other\" is among the use_case tags."
- Changed
request_upload1 field changed- removed
Input schema / properties / count / descriptionRemoved 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."
- Changed
time_series20 fields changed- removed
Input schema / properties / bucket / descriptionRemoved value: -"Bucket size." - removed
Input schema / properties / filter / descriptionRemoved value: -"Subset of transactions to operate on. All fields are optional and combined with AND logic." - removed
Input schema / properties / filter / properties / accounts / descriptionRemoved value: -"Account number slugs to include." - removed
Input schema / properties / filter / properties / amountMax / descriptionRemoved value: -"Inclusive maximum absolute amount." - removed
Input schema / properties / filter / properties / amountMin / descriptionRemoved value: -"Inclusive minimum absolute amount." - removed
Input schema / properties / filter / properties / category / descriptionRemoved value: -"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"." - removed
Input schema / properties / filter / properties / currency / descriptionRemoved value: -"ISO 4217 currency code. E.g. \"USD\", \"HKD\"." - removed
Input schema / properties / filter / properties / dateEnd / descriptionRemoved value: -"ISO date (YYYY-MM-DD). Inclusive upper bound." - removed
Input schema / properties / filter / properties / dateStart / descriptionRemoved value: -"ISO date (YYYY-MM-DD). Inclusive lower bound." - removed
Input schema / properties / filter / properties / direction / descriptionRemoved value: -"Semantic direction." - removed
Input schema / properties / filter / properties / merchant / descriptionRemoved value: -"Substring match against description or counterparty (case-insensitive)." - removed
Input schema / properties / filter / properties / text / descriptionRemoved value: -"Whole-row text search over raw transaction fields (case-insensitive)." - removed
Input schema / properties / metric / descriptionRemoved value: -"Metric per bucket." - removed
Input schema / properties / scope / descriptionRemoved 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)." - removed
Input schema / properties / scope / properties / accounts / descriptionRemoved value: -"Account/product chips (kind + identityKey) to scope to. Empty = all accounts." - added
Input schema / properties / scope / properties / accounts / items / anyOfAdded 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" + } +] - removed
Input schema / properties / scope / properties / accounts / items / oneOfRemoved 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" - } -] - removed
Input schema / properties / scope / properties / dateRange / descriptionRemoved value: -"Bounds results to transactions within this date range. Omit for no date filter." - removed
Input schema / properties / scope / properties / dateRange / properties / from / descriptionRemoved value: -"Start of the date range (inclusive), YYYY-MM-DD." - removed
Input schema / properties / scope / properties / dateRange / properties / to / descriptionRemoved value: -"End of the date range (inclusive), YYYY-MM-DD."
- Changed
top_n21 fields changed- removed
Input schema / properties / dimension / descriptionRemoved value: -"Grouping dimension." - removed
Input schema / properties / filter / descriptionRemoved value: -"Subset of transactions to operate on. All fields are optional and combined with AND logic." - removed
Input schema / properties / filter / properties / accounts / descriptionRemoved value: -"Account number slugs to include." - removed
Input schema / properties / filter / properties / amountMax / descriptionRemoved value: -"Inclusive maximum absolute amount." - removed
Input schema / properties / filter / properties / amountMin / descriptionRemoved value: -"Inclusive minimum absolute amount." - removed
Input schema / properties / filter / properties / category / descriptionRemoved value: -"Category slug, e.g. \"meals_entertainment\", \"groceries_personal\"." - removed
Input schema / properties / filter / properties / currency / descriptionRemoved value: -"ISO 4217 currency code. E.g. \"USD\", \"HKD\"." - removed
Input schema / properties / filter / properties / dateEnd / descriptionRemoved value: -"ISO date (YYYY-MM-DD). Inclusive upper bound." - removed
Input schema / properties / filter / properties / dateStart / descriptionRemoved value: -"ISO date (YYYY-MM-DD). Inclusive lower bound." - removed
Input schema / properties / filter / properties / direction / descriptionRemoved value: -"Semantic direction." - removed
Input schema / properties / filter / properties / merchant / descriptionRemoved value: -"Substring match against description or counterparty (case-insensitive)." - removed
Input schema / properties / filter / properties / text / descriptionRemoved value: -"Whole-row text search over raw transaction fields (case-insensitive)." - removed
Input schema / properties / metric / descriptionRemoved value: -"Metric to rank by." - removed
Input schema / properties / n / descriptionRemoved value: -"Number of top groups to return." - removed
Input schema / properties / scope / descriptionRemoved 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)." - removed
Input schema / properties / scope / properties / accounts / descriptionRemoved value: -"Account/product chips (kind + identityKey) to scope to. Empty = all accounts." - added
Input schema / properties / scope / properties / accounts / items / anyOfAdded 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" + } +] - removed
Input schema / properties / scope / properties / accounts / items / oneOfRemoved 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" - } -] - removed
Input schema / properties / scope / properties / dateRange / descriptionRemoved value: -"Bounds results to transactions within this date range. Omit for no date filter." - removed
Input schema / properties / scope / properties / dateRange / properties / from / descriptionRemoved value: -"Start of the date range (inclusive), YYYY-MM-DD." - removed
Input schema / properties / scope / properties / dateRange / properties / to / descriptionRemoved value: -"End of the date range (inclusive), YYYY-MM-DD."
4 tool updates
- Changed
convert_statement2 fields changed- added
Input schema / properties / upload_idsAdded 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" +} - added
Output schema / properties / resultsAdded 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" +}
- Changed
get_credits2 fields changed- added
Output schema / properties / planAdded value: +{ + "additionalProperties": false, + "properties": { + "dailySpendCap": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "maxPagesPerUpload": { + "type": "number" + }, + "maxUploadSizeMb": { + "type": "number" + } + }, + "required": [ + "maxPagesPerUpload", + "maxUploadSizeMb", + "dailySpendCap" + ], + "type": "object" +} - changed
Output schema / requiredPrevious value: -[ - "balance", - "limit", - "planId", - "creditsExpireAt", - "summary" -]New value: +[ + "balance", + "limit", + "planId", + "creditsExpireAt", + "plan", + "summary" +]
- Changed
get_statement1 field changed- added
Output schema / properties / resultsAdded 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" +}
- Changed
request_upload3 fields changed- added
Input schema / properties / countAdded 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" +} - added
Output schema / properties / uploadsAdded value: +{ + "items": { + "additionalProperties": false, + "properties": { + "upload_id": { + "type": "string" + }, + "upload_url": { + "type": "string" + } + }, + "required": [ + "upload_id", + "upload_url" + ], + "type": "object" + }, + "type": "array" +} - removed
Output schema / requiredRemoved value: -[ - "upload_id", - "upload_url", - "expires_at", - "max_bytes" -]
1 tool update
- Changed
list_transfers2 fields changed- added
Input schema / properties / amountMinAdded 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" +} - added
Output schema / properties / unmatchedAdded value: +{ + "additionalProperties": {}, + "properties": {}, + "type": "object" +}
15 tool updates
- First observed
aggregate - First observed
categorize_statement - First observed
compare - First observed
convert_statement - First observed
evaluate_benchmark - First observed
get_credits - First observed
get_statement - First observed
group_by - First observed
list_statements - First observed
list_transactions - First observed
list_transfers - First observed
rate_statement - First observed
request_upload - First observed
time_series - First observed
top_n
Related MCP Connectors
Turn bank statement PDFs into categorized, balance-checked transactions and reports.
Convert PDF bank statements to checked Excel, CSV or JSON with balance validation.
Turn bank statement PDFs, CSVs, XLSX and OFX into categorised transactions plus a summary.
Turn any PDF into structured JSON via AI + OCR: invoices, bank statements, contracts.
Related MCP Servers
- AlicenseAqualityCmaintenanceConverts PDF bank statements into structured data (Markdown, JSON, CSV, JSONL) with verified transactions and balance checks, enabling agents to audit numbers.53 npmMIT
- AlicenseAqualityAmaintenanceConverts 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.5MIT
- AlicenseAqualityDmaintenanceConvert PDFs to structured JSON. Extract invoices, bank statements, contracts, and more. Pay per call via x402 USDC.58MIT
- AlicenseAqualityCmaintenanceEnables parsing German bank statement PDFs into structured, validated transaction data, exporting all transactions as German-style CSV, and verifying statement totals via proof calculations, all locally within MCP-compatible clients.3MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.