ksef-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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| server_infoA | Report the name and version of the running KSeF connector. |
| list_recent_invoicesA | List the invoice metadata of the last thirty days, per subject type. Takes no arguments, for the same reason Reads only. There is no confirmation to click: a gate on a read teaches the person to approve without looking, and spends the gate that a write needs. At most fifty invoices are listed individually. Above that the rows are
dropped and the answer carries the count and the gross total per currency
instead — and Metadata only. An FA(2)/FA(3) body holds a counterparty's personal data and is third-party input; it never enters this answer. |
| render_invoice_pdfA | Write one archived invoice as the PDF the Ministry's own application shows.
The document is produced by the Ministry's own generator, run locally from a
build vendored with this package — the same code the verification portal
loads into a browser. Fidelity is therefore official rather than
approximate, and
On production the document carries the QR code and verification link, and
Requires Node — The generator accepts FA(1), FA(2), FA(3), UPO and PEF, but only FA(3) has been exercised end to end. Treat a refusal on an older schema as untested rather than impossible, and report it. |
| review_new_invoicesA | Report the invoices that have arrived since a person was last shown any. This is the question the free Ministry application cannot answer: it lists what is there, never what is new since somebody last looked. The comparison is against a ledger of KSeF numbers already reported by this tool, kept on disk per subject and per environment, so it survives restarts. The window is the last ninety days, dated by acceptance in KSeF rather than by the seller's issue date — an invoice issued in March and accepted yesterday is new to the reader, and a window dated by issue date would not contain it. Both ends are fixed, so asking again within the same hour is answered from disk and spends nothing from twenty metadata queries an hour.
KSeF has no notion of a closed period and will not stop an invoice from
landing in a month already filed, so Invoices listed individually are recorded as shown, and the next call does
not repeat them. Above the threshold the rows are dropped, and then nothing
is recorded, because nobody saw them — |
| export_period_statementA | Write one month of purchase invoices as a CSV an accountant can forward.
The file holds ten columns, in this order: KSeF number, the seller's own invoice number, issue date, seller NIP, seller name, gross, net, VAT, currency, and a KOD I verification code. The code is composed from the seller NIP, the issue date and the SHA-256 of the archived invoice body; rows whose body is not in the archive yet say so instead of carrying a blank code. Addresses, bank accounts, invoice lines and local paths are absent on purpose: this file is written to be attached to an e-mail. The paths are in this answer instead. Amounts are written exactly as KSeF stated them — no rounding, no float anywhere on the path — with a comma as the decimal separator and a semicolon between fields, which is what a Polish spreadsheet expects. Sums are in this answer, per currency, and never one figure across several of them. |
| synchronise_invoicesA | Fetch, decrypt and archive every invoice package KSeF finished since the last run. Takes no arguments on purpose. The date window, the package size and how many packages to ask for are decided by KSeF and by the hourly allowance, never by the caller: an agent driving them spends a twenty-per-hour budget in two minutes and the Ministry reads the pattern as working around a limit. Safe to call again. A package still being built, or one fetched but not yet
stored, stays recorded on disk with its key, so a second call continues it
instead of asking for it twice. An invoice already in the archive is
reported under Reports where the invoices landed and which KSeF numbers arrived. It never returns invoice content: an FA(2)/FA(3) document holds a counterparty's personal data, and reading one means opening the file this tool names.
|
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 6 tools
Each tool targets a distinct operation—sync, list, review, export CSV, render PDF, and server info—and the descriptions are unusually explicit about boundaries. The only potential confusion is between the two metadata-listing tools (list_recent_invoices and review_new_invoices), whose similar output shapes are nevertheless sharply distinguished as a fixed 30-day window versus a since-last-seen ledger.
Five of the six tools follow a consistent snake_case verb_object pattern: export_period_statement, render_invoice_pdf, list_recent_invoices, review_new_invoices, synchronise_invoices. server_info breaks the pattern as a bare noun phrase rather than a verb-led command, which is a minor but real deviation.
Six tools is well-scoped for a domain-specific connector: one ingestion tool, two exposure/list tools, two output tools, and one informational tool. Each earns its place with no redundancy or filler.
The core workflow is fully traversable: synchronise brings invoices into the archive, list/review surface what arrived, and export/render produce the accountant-facing deliverables. The main gaps are the absence of a metadata lookup by a specific KSeF number and no way to list or search invoices older than the 30-day window, which agents would need to work around.