Loading ToolBench
Model Context Protocol server for Ksefnik — exposes KSeF reconciliation tools to Claude, Cursor and other MCP clients
The MCP server defines 9 tools with basic schemas and descriptions, but falls short of production quality in several critical areas. All tools have descriptions and input schemas with type information, which is a baseline requirement. However, descriptions are minimal (most under 100 chars), parameters lack depth in their documentation, output schemas are not documented, and there is no evidence of error handling guidance or recovery patterns. The tool names follow verb_noun convention adequately (sync-invoices, import-bank, reconcile, get-unmatched, query-invoices, send-invoice, validate-invoice, confirm-match, get-upo), which is good. However, parameter descriptions are sparse and do not explain constraints, formats, or when to use each parameter. For example, 'from' and 'to' parameters in sync-invoices lack guidance on date format beyond 'ISO 8601 format', no min/max, no examples, no guidance on what happens if the range is invalid. The query-invoices tool accepts four optional parameters (nip, from, to, invoiceNumber) but does not document mutually-exclusive relationships or which combinations are valid. Output schemas are completely absent, the agent cannot know what fields to expect from sync-invoices, reconcile, or get-upo. Error handling is not visible in the provided code; there is no indication of how the tools communicate failure modes, which errors are retryable, or what recovery steps the LLM should take.
Confirm or reject a reconciliation match
Get unmatched invoices and transactions from a reconciliation report
Check UPO (Urzędowe Poświadczenie Odbioru) status for a sent invoice
Import bank statement content (auto-detects format)
Query stored invoices by NIP, date range, or invoice number
Run reconciliation pipeline on stored invoices and transactions
Send invoice XML to KSeF
reconcile tool has no input parameters documented; it is unclear what state it operates on, whether it accepts any configuration, or how to invoke it correctly
No output schemas documented for any tool. LLMs cannot plan downstream tool calls or know what fields to extract from responses. For example, sync-invoices result structure is unknown.
Parameter descriptions are minimal and lack constraint documentation. 'from' and 'to' parameters lack guidance on min/max dates, whether past dates are allowed, behavior if end < start, etc. LLMs will guess at invalid inputs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Fetch invoices from KSeF for a given date range
Validate an invoice against 20 Polish tax rules
query-invoices accepts four optional parameters (nip, from, to, invoiceNumber) with no documentation of valid combinations, mutual exclusivity, or priority. LLMs cannot determine which to use.
import-bank description does not explain the auto-detection mechanism, whether it validates the content before import, what happens on malformed input, or what the tool returns. LLM reasoning on error cases is impossible.
send-invoice and confirm-match are write operations but lack confirmation or dry-run guidance. An agent could accidentally send invalid invoices or confirm incorrect matches without recourse.
No error handling patterns visible. Tools do not indicate which errors are retryable, what the LLM should do if an invoice is invalid, or how to recover from a failed reconciliation.
validate-invoice description says 'against 20 Polish tax rules' but does not explain what those rules are, what validation failures look like, or how the agent should act on validation errors.
get-unmatched and get-upo both accept IDs but parameter descriptions do not explain the ID format (is it a UUID, a numeric ID, a KSeF reference?), where to obtain the ID, or what happens if the ID is invalid.