szamlazz-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| password | Yes | Your Számlázz.hu password, set in ~/.szamlazz-mcp/config.json. Note: the account must not use two-factor authentication, and write tools require a user belonging to only one company. | |
| username | Yes | Your Számlázz.hu username (email), set in ~/.szamlazz-mcp/config.json (Windows: C:\Users\<you>\.szamlazz-mcp\config.json) |
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 |
|---|---|
| list_companiesA | The companies the configured Számlázz.hu login can work in (read from Számlázz.hu), and which one the tools use when no company is given. Switch per call: pass the company name or id in the other tools' company parameter. |
| list_invoicesA | Outgoing invoices (newest first), searchable by invoice number or buyer name, paged. Per row: invoice number, dates, buyer, totals, paid, outstanding. |
| get_invoice_dataB | Data of an outgoing invoice by invoice number: seller, buyer, items, totals, amount paid and outstanding. Optionally the PDF too. |
| get_invoice_pdfA | PDF of an existing outgoing invoice by invoice number. The PDF comes attached to the answer; nothing is saved to disk. |
| get_receiptB | Data and PDF of a receipt by receipt number. |
| list_bank_transactionsA | Bank transactions for a period (id, reference, value date, amount, partner, direction). Read from the Számlázz.hu web interface. No matching status included. |
| create_invoiceB | Issue a new invoice (normal, proforma, advance or correction invoice). The PDF comes attached to the answer. |
| reverse_invoiceB | Reverse an invoice: issues the reversing invoice for the original. |
| register_paymentB | Register payments on an invoice. At most 5 payment entries per invoice. |
| delete_proformaB | Delete a proforma invoice by invoice number or order number. |
| create_receiptC | Issue a new receipt with items and an optional payment breakdown. |
| reverse_receiptC | Reverse a receipt by receipt number. |
| send_receiptA | E-mail a receipt to the given address. |
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 13 tools
Most tools target distinct resources and actions, and descriptions clearly separate listing, data retrieval, creation, reversal, payment, and sending. The main overlap is between get_invoice_data and get_invoice_pdf, since get_invoice_data can optionally include the PDF, and get_receipt bundles data plus PDF unlike the split invoice tools.
All names use predictable snake_case with a leading verb such as list_, get_, create_, reverse_, register_, delete_, or send_. The minor subtype naming in delete_proforma and get_invoice_pdf still follows the same overall verb_noun convention.
The 13 tools are well scoped for an invoicing and receipt service, with each tool covering a meaningful operation. The set is neither thin nor bloated.
Core invoice and receipt workflows are covered, including creation, retrieval, reversal, payment registration, and receipt sending. However, there is no list_receipts or receipt search, making it hard to discover receipt numbers, and there is no send_invoice equivalent to send_receipt, creating notable gaps in the receipt and invoice lifecycle.