Skip to main content
Glama

MainBook Bank Statement Converter

by ai.mainbook

Convert bank statement

convert_bank_statement

Convert one PDF bank statement through the complete MainBook workflow: create a job, upload, start, poll, and return structured data. This creates a job and spends page credits; it is not read-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
file_urlNoPublic HTTPS URL of a PDF for remote mode. Redirects and non-public network addresses are rejected. Exactly one source is required.
file_pathNoPath to a PDF on the MCP server machine. This field is only available over stdio and is rejected in HTTP mode; remote clients must use file_url. The path must be inside the allowed folders, which default to Downloads, Desktop, and Documents. Exactly one of file_path and file_url is required.
output_pathNoOptional absolute result file or existing folder on the MCP server machine. Only available over stdio and only inside the allowed folders. The file extension is corrected to match result_type.
result_typeNoJSON is returned inline. Over stdio, XLSX or CSV is written to an allowed local folder and the full path is returned. HTTP mode returns safe download instructions. Binary bytes never enter model context.json
idempotency_keyNoOptional value forwarded verbatim in the Idempotency-Key REST header.
timeout_secondsNoInternal polling budget from 30 to 900 seconds. Timeout leaves the job running and returns its job_id for get_conversion. The default stays under the 60-second request timeout most MCP clients enforce; a client that gives up first discards the job_id and the conversion looks lost.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNo
pagesYes
stateYes
job_idYes
messageYes
downloadNo
timed_outNo
saved_fileNo
validationYes
result_typeYes

TDQS

A4.2/5.0
Behavior4/5

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

Beyond annotations (readOnlyHint=false, openWorldHint=true), the description discloses that it creates a job, spends page credits, and is not read-only. It adds meaningful context about side effects and cost, which is valuable and consistent with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is two tight sentences that front-load the core purpose and key behavioral caveats. Every sentence earns its place without redundancy.

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

Completeness4/5

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

Given the tool's complexity (6 params, workflow, async behavior), the description covers essential aspects: job creation, credit usage, async completion via job_id, and non-read-only nature. The detailed schema and output schema compensate for any omitted return-value details.

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

Parameters3/5

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

Schema coverage is 100% with rich parameter descriptions (transport methods, allowed folders, result_type behavior, timeout semantics). The tool description adds no per-parameter meaning, so baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly specifies the action ('convert one PDF bank statement') and resource, and outlines the complete workflow. It distinguishes from sibling read-only tools (get_balance, get_conversion, list_conversions) by explicitly stating it creates a job and is not read-only.

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

Usage Guidelines4/5

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

Clear context for when to use this tool: to convert a PDF, with details about the workflow and timeout behavior pointing to get_conversion. It does not explicitly list exclusions or alternatives, but the timeout returns job_id for get_conversion, which indirectly guides the agent.

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

All MainBook Bank Statement Converter toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a distinct, non-overlapping purpose: convert initiates a full workflow, get_balance queries credits, get_conversion retrieves a specific job's state, and list_conversions enumerates jobs. No ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern: convert_bank_statement, get_balance, get_conversion, list_conversions. The convention is uniform and predictable.

Tool Count5/5

Four tools is well-scoped for a bank statement converter: one primary conversion action plus three supporting query/status operations. No bloat or missing core functionality.

Completeness4/5

The set covers the full conversion lifecycle (create, upload, start, poll, retrieve) along with credit checking and job listing. A minor gap is the lack of an explicit cancel/delete operation, but this is not a critical workflow dead-end.

Resources