Skip to main content
Glama
Sign In
pdfvera MCP server

pdfvera MCP server

Official
by pdfvera
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Brazilian bank statement PDF to OFX, CSV and Excel

convert_bank_statement
Idempotent

Convert Brazilian bank statement PDFs into OFX, CSV, and Excel, checking entries against printed balances so files are written only when reconciled.

Instructions

Convert a Brazilian bank statement PDF (extrato bancário) into OFX for an accounting system, CSV and Excel. The entries are summed and checked against the balances printed in the statement; files are only written when the balance reconciles. Password-protected PDFs need password (or cpf to try the banks' usual passwords). Each converted statement counts once against the monthly quota of the user's pdfvera plan; check_only never counts.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "pdf_path": "<pdf_path>"
    },
    "name": "convert_bank_statement"
  }
}

Input Schema

NameRequiredDescriptionDefault
cpfNoAccount holder's CPF, to try the banks' usual passwords
profileNoAccounting system the OFX is fordominio
passwordNoPDF password
pdf_pathYesPath of the statement PDF on this computer
check_onlyNoOnly check, write no files and use no quota
output_dirNoFolder for the result files; default: the PDF's folder

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: entries are summed and reconciled against printed balances, and files are written only when reconciliation succeeds. It also discloses the quota model (one count per converted statement) and that check_only never counts, which the readOnlyHint=false/idempotentHint=true annotations cannot convey.

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

Conciseness4/5

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

Four tight sentences, front-loaded with what is produced and what gate must pass before anything is written. The bilingual parenthetical is useful for matching, not filler; only the quota sentence is slightly redundant with the schema.

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

Completeness4/5

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

For a writing tool with no output schema, it covers the critical unknowns: the reconciliation gate, quota cost, and password handling. What remains unstated is the failure outcome when balances do not reconcile (error vs. report) and the naming of emitted files.

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

Parameters3/5

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

Schema coverage is 100%, so all six parameters are already documented, and the description mostly restates them (password/cpf, check_only). The only real addition is tying check_only to the quota exemption, which the schema phrase 'use no quota' already implies. 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?

States a specific verb (convert) plus resource (Brazilian bank statement PDF) and enumerates the exact output formats (OFX, CSV, Excel). The Portuguese term '(extrato bancário)' and the specific input domain make it trivially distinguishable from convert_invoice.

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?

Gives clear situational guidance: use `password` for protected PDFs, `cpf` to attempt the banks' usual passwords, and `check_only` when you want validation without file writes or quota spend. It stops short of any explicit when-not-to-use or a direct pointer to convert_invoice/get_usage, but the conditions it does cover are concrete.

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

Deploy Server

Other Tools