MainBook Bank Statement Converter

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

Name	Required	Description	Default
`file_url`	No	Public HTTPS URL of a PDF for remote mode. Redirects and non-public network addresses are rejected. Exactly one source is required.
`file_path`	No	Path 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_path`	No	Optional 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_type`	No	JSON 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_key`	No	Optional value forwarded verbatim in the Idempotency-Key REST header.
`timeout_seconds`	No	Internal 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

Name	Required	Description	Default
`data`	No
`pages`	Yes
`state`	Yes
`job_id`	Yes
`message`	Yes
`download`	No
`timed_out`	No
`saved_file`	No
`validation`	Yes
`result_type`	Yes

TDQS

A4.4/5.0

Behavior5/5

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

The description reveals the internal workflow steps, notes that it 'spends page credits', and explicitly disclaims read-only status. This adds meaningful behavioral context beyond the annotations, which only provide readOnlyHint=false.

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

Conciseness5/5

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

Two sentences front-load the purpose and cost/behavior with no filler. Every clause contributes useful information about workflow and side effects.

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?

The description gives a high-level workflow overview, while the schema covers detailed behavior such as timeout handling, result types, file/source constraints, and idempotency. Given the output schema and rich annotations, it is sufficiently complete for an agent.

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?

All six parameters have full descriptions in the schema (100% coverage), and the tool description itself does not add parameter-level detail. The schema carries the semantic load, 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.

Purpose5/5

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

The description opens with 'Convert one PDF bank statement through the complete MainBook workflow', using a specific verb and resource. It distinguishes itself from read-only sibling tools by stating it creates a job, spends page credits, 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?

It clearly frames the tool as the full conversion workflow ('create a job, upload, start, poll, and return structured data') and warns 'it is not read-only', so an agent knows when to use it. It does not explicitly name alternatives like get_conversion for subsequent polling, but the context is clear enough.

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 tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: starting a conversion, checking credits, retrieving a specific conversion, and listing conversions. There is no overlap or ambiguity among the four tools.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: convert_bank_statement, get_balance, get_conversion, list_conversions. This makes the naming predictable and easy to reason about.

Tool Count5/5

With exactly 4 tools, the set is well-scoped for a bank statement converter. Each tool covers an essential part of the workflow without unnecessary redundancy or bloat.

Completeness5/5

The tool surface covers the full lifecycle: initiating a conversion, checking credit balance, retrieving results, and listing past jobs. There are no significant gaps for the stated purpose of converting and retrieving bank statements.

Resources

Need Help?