kontozack-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| parse_bank_statementA | Parses a German bank statement PDF (currently: SumUp account statements) into structured transactions. Returns statement header data (IBAN, period, balances), the number of transactions, proof-calculation validation checks (parsed sums must match the statement's own header totals), and the transactions themselves (truncated above 500 – use export_bank_statement_csv for the full data). More bank formats: https://kontozack.de |
| export_bank_statement_csvA | Parses a German bank statement PDF (currently: SumUp) and writes all transactions to a German-style CSV file: semicolon separator, comma decimals, UTF-8 BOM (opens cleanly in German Excel; suitable as DATEV import basis). Returns the number of data rows and the output path. |
| validate_bank_statementA | Parses a German bank statement PDF (currently: SumUp) and runs only the proof-calculation checks: the sums of the parsed transactions must match the statement's own header totals (incoming, outgoing incl. fees, balance delta) and every row must carry a running balance. Use this to verify a statement was read completely and correctly. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a distinct primary outcome: structured parse, CSV export, and validation-only. However, parse_bank_statement already returns proof-calculation validation checks, so it partially overlaps with validate_bank_statement, and all three re-parse the same PDF, which could cause selection confusion.
All three tools follow a clean verb_noun snake_case pattern: parse_bank_statement, export_bank_statement_csv, validate_bank_statement. The shared domain suffix makes the pattern predictable and readable.
Three tools is on the lean side but each maps to a genuine need (parse, export, validate) for a narrow PDF-parsing domain. Nothing is redundant enough to warrant trimming, though the surface is thin.
The parse/export/validate lifecycle is covered, but only SumUp statements and only one export format (German CSV) are supported; no other bank formats, no alternate output formats, and no listing of supported statements despite the description pointing to more formats externally.