A
licenseA
qualityC
maintenanceConverts PDF bank statements into structured data (Markdown, JSON, CSV, JSONL) with verified transactions and balance checks, enabling agents to audit numbers.
5
20
MIT
MainBook Bank Statement Converter
by ai.mainbook
Server Details
Convert PDF bank statements to checked Excel, CSV or JSON with balance validation.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- human-beyond/mainbook-mcp
- GitHub Stars
- 0
- Server Listing
- MainBook Bank Statement Converter
Available Tools
4 toolsconvert_bank_statementConvert bank statementAInspect
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.
ParametersJSON 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| 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.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.
get_balanceGet page-credit balanceARead-onlyInspect
Return total, reserved, and available MainBook credits. Every value is measured in PDF pages.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| units | No | |
| balance | Yes | |
| reserved | Yes | |
| available | Yes | |
| explanation | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states that values are in PDF pages, which goes beyond the readOnlyHint annotation (which already marks it as safe/read-only). The openWorldHint annotation is present but the description adds the specific unit detail. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that capture the tool's purpose and the unit of measurement. Every word adds value, and it is perfectly front-loaded with the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters, an output schema exists to define return values, and there are no complex behavioral traits, the description is fully adequate. It is complete for the intended use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100%, so there is no burden for the description to explain parameter meaning. The description does not add any additional parameter semantics, which is fine—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 uses specific verbs ('Return') and clearly identifies the resource ('total, reserved, and available MainBook credits') and the unit ('measured in PDF pages'). It is distinct from sibling tools like 'convert_bank_statement' or 'get_conversion' which deal with conversion operations, not balance retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Although there is no explicit 'when to use' versus 'alternatives' statement, the context signals show zero parameters and the sibling tools are all about conversion—not balance. The description implicitly makes clear that this is a straightforward query tool with no filtering needed, and no trade-offs exist among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_conversionGet conversionARead-onlyIdempotentInspect
Get the current state of one MainBook conversion. When successful, return JSON inline or save XLSX/CSV locally over stdio. HTTP mode returns safe download instructions. Use this after convert_bank_statement times out.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Conversion job UUID returned by MainBook. | |
| 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. | |
| result_type | No | Result representation to retrieve after the job succeeds. | json |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| 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
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond annotations: successful jobs return JSON inline or save XLSX/CSV files locally over stdio, while HTTP mode returns safe download instructions. This clarifies surprising mode-dependent behavior without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence states the core action, and the second covers result behavior and usage timing. Every clause contributes meaningful information.
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 output schema covers return values, so the description does not need to detail them. It covers the main execution modes and when to call the tool, but it does not describe the polling lifecycle or failure/status behavior in depth. Given the presence of a rich schema and clear annotations, this is still a solidly complete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by linking output delivery to stdio vs HTTP modes, which enriches the meaning of result_type and output_path beyond the schema. It does not restate the parameter details, making it a useful complement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get the current state of one MainBook conversion.' It distinguishes this from siblings like list_conversions (plural listing) and convert_bank_statement (creation trigger) by focusing on a single conversion's state and result retrieval.
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 explicitly tells the agent when to use the tool: 'Use this after convert_bank_statement times out.' This provides clear timing context. It does not explicitly mention alternatives or when not to use it, but the purpose and predecessor relationship are clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_conversionsList conversionsARead-onlyInspect
List one cursor page of conversion jobs visible to the MainBook account. Pass the returned next_cursor to continue.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Jobs on this page, from 1 to 100. | |
| cursor | No | Opaque next_cursor from the previous page. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| units | No | |
| conversions | Yes | |
| next_cursor | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, so the safety profile is clear. The description adds meaningful context: the list is scoped to the MainBook account and it returns only one cursor page at a time. This goes beyond the 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, the first stating the purpose and scope, the second providing the primary usage instruction. Every word is necessary; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two parameters and an output schema (indicated present), the description covers the core purpose, pagination pattern, and account scope. It does not need to explain return values because the output schema handles that. The description is sufficient for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for both limit and cursor with clear descriptions. The tool description reinforces the cursor usage ('Pass the returned next_cursor to continue') but does not add new semantics beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'conversion jobs' and immediately clarifies the scope ('one cursor page', 'visible to the MainBook account'). This clearly distinguishes it from sibling tools like get_conversion (single item) and convert_bank_statement (different action).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to use the returned next_cursor to continue pagination, which is a clear usage pattern. However, it does not explicitly state when not to use this tool versus its siblings (e.g., 'for a single conversion use get_conversion instead'), but the context signals (sibling names) make the distinction inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
2 tool updates
- Changed
convert_bank_statement6 fields changed- added
Output schema / $defs / DownloadInstruction / properties / expires_atAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Expires At" +} - added
Output schema / $defs / DownloadInstruction / properties / rest_endpoint / anyOfAdded value: +[ + { + "type": "string" + }, + { + "type": "null" + } +] - added
Output schema / $defs / DownloadInstruction / properties / rest_endpoint / defaultAdded value: +null - removed
Output schema / $defs / DownloadInstruction / properties / rest_endpoint / typeRemoved value: -"string" - added
Output schema / $defs / DownloadInstruction / properties / urlAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Url" +} - changed
Output schema / $defs / DownloadInstruction / requiredPrevious value: -[ - "job_id", - "result_type", - "rest_endpoint", - "instruction" -]New value: +[ + "job_id", + "result_type", + "instruction" +]
- Changed
get_conversion6 fields changed- added
Output schema / $defs / DownloadInstruction / properties / expires_atAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Expires At" +} - added
Output schema / $defs / DownloadInstruction / properties / rest_endpoint / anyOfAdded value: +[ + { + "type": "string" + }, + { + "type": "null" + } +] - added
Output schema / $defs / DownloadInstruction / properties / rest_endpoint / defaultAdded value: +null - removed
Output schema / $defs / DownloadInstruction / properties / rest_endpoint / typeRemoved value: -"string" - added
Output schema / $defs / DownloadInstruction / properties / urlAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Url" +} - changed
Output schema / $defs / DownloadInstruction / requiredPrevious value: -[ - "job_id", - "result_type", - "rest_endpoint", - "instruction" -]New value: +[ + "job_id", + "result_type", + "instruction" +]
1 tool update
- Removed
output_folder
5 tool updates
- First observed
convert_bank_statement - First observed
get_balance - First observed
get_conversion - First observed
list_conversions - First observed
output_folder
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Convert PDF bank statements into structured transactions, accounts, and balances.
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.
PDF tools + invoice extraction, bank statement parsing, GST reconciliation & GSTIN validation.
Related MCP Servers
bankstatementlyofficial
AlicenseNot gradedqualityAmaintenanceParse and query bank statements — turn PDF statements into structured transactions, accounts, and balances, with balance-reconciliation checks. A deterministic financial memory for AI agents, served as a hosted streamable-HTTP endpoint (API key or OAuth).1MIT- AlicenseNot gradedqualityCmaintenanceParse crypto exchange CSVs (Coinbase, Binance, Kraken, +11 more) and bank statement PDFs (Chase, BofA, +11 more) into Koinly, TurboTax, CoinLedger, or ZenLedger formats. Free tier: 25 files/month, no credit card required.3ISC
- AlicenseAqualityBmaintenanceConvert PDFs to structured JSON. Extract invoices, bank statements, contracts, and more. Pay per call via x402 USDC.58MIT
Try in Browser
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.