Hungary Invoice MCP 🇭🇺 — How can my AI agent report an invoice to NAV Online Számla (számla adatszolgáltatás)?
Use it in 60 seconds
Paste this into your MCP client config (Claude Desktop, Cursor, Windsurf, or any MCP-capable agent):
{
"mcpServers": {
"hungary-invoice": {
"type": "http",
"url": "https://inv-hu.wishpool.app/mcp"
}
}
}
Nothing to install. Credentials, when you need them, travel as HTTP headers on each request and are never stored — see the threat model.
Or run it yourself
Would you rather not send production credentials to a server you do not control? Deploy this identical code to your own account and point your agent at your own URL:
git clone https://github.com/junter1989k-ai/hungary-invoice-mcp && cd hungary-invoice-mcp && npx vercel --prod
MIT-licensed. Self-hosting removes us from the picture entirely, at no cost and with no loss of function.
Remote MCP server that lets any AI agent report Hungary invoice data to NAV Online Számla 3.0 — the Hungarian tax authority's national invoice-data reporting API (számla adatszolgáltatás). It builds the InvoiceData XML, runs the signed token-exchange + manageInvoice flow, and returns the government transactionId. Stateless, bring-your-own credentials, never stores anything.
This is reporting, not issuing. NAV Online Számla is a data-reporting system: the merchant issues the actual invoice to the buyer with their own invoicing software, and — as required by Hungarian law — reports the invoice data to NAV. This server does that reporting step; it does not deliver invoices to buyers.
Live endpoint: https://inv-hu.wishpool.app/mcp · Registry: app.wishpool/hungary-invoice-mcp
Quick start
{
"mcpServers": {
"hungary-invoice": {
"type": "http",
"url": "https://inv-hu.wishpool.app/mcp",
"headers": {
"x-nav-login": "your-technical-user-login",
"x-nav-password": "your-technical-user-password",
"x-nav-signkey": "your-signature-key",
"x-nav-exchangekey": "your-16-byte-exchange-key",
"x-nav-taxnumber": "12345678",
"x-nav-mode": "prod"
}
}
}
}
Self-mint all five keys as a technical user in the Online Számla web portal (onlineszamla.nav.gov.hu → Technical users). Omit x-nav-mode to stay in the NAV TEST environment (no legal effect). Your keys stay with you — this server never stores them.
| Tool | What it does |
|---|
submit_invoice | Report an invoice to NAV — supplier_name, customer_name (+ optional customer_tax_number for B2B), invoice_number, items (name, quantity, unit_net_price, vat_rate 27/18/5/0) in, transactionId out. Supplier tax number comes from the header; per-rate net/VAT and the gross total are computed for you (HUF). Omit customer_tax_number for a private person. |
query_transaction | Read the NAV processing status by transactionId: RECEIVED / PROCESSING / SAVED / DONE (success terminal) / ABORTED (rejected — see validation_messages). |
Owner policy guardrails ride optional headers (x-agentpay-max-amount, x-agentpay-approval-above, x-agentpay-allowed-tools) — set by the human owner in client config; the agent cannot relax them. The cap applies to the invoice gross total (HUF).
Scope & honest gaps
- CREATE only in v0.1. Correcting or cancelling a reported invoice (
MODIFY / STORNO operations) is a separate reporting flow kept out of this version to stay focused. To correct a mistake, issue a modifying/cancelling invoice to the buyer and report it.
- HUF only. Foreign-currency invoices (with
exchangeRate) are not supported yet.
- Domestic B2B / private person.
customerVatStatus is DOMESTIC (with buyer tax number) or PRIVATE_PERSON (without). OTHER (foreign) buyers and special cases (margin scheme, reverse charge, EKÁER, product codes) are out of scope for v0.1.
How it works (NAV Online Számla 3.0 flow)
- Token exchange:
POST /tokenExchange — sign the request with SHA3-512 over requestId + timestamp(yyyyMMddHHmmss) + signKey, hash the password with SHA-512; NAV returns encodedExchangeToken, which we AES-128-ECB decrypt with your exchange key.
- Report: build the
InvoiceData XML (namespace schemas.nav.gov.hu/OSA/3.0/data), base64 it, and POST /manageInvoice with a CREATE operation. The manageInvoice signature is index-chained: SHA3-512( requestId + timestamp + signKey + SHA3-512(operation + base64data) ). NAV returns a transactionId.
- Status:
POST /queryTransactionStatus with that transactionId returns the per-invoice invoiceStatus and any technical/business validation messages.
The password hash, request signature and token decryption all happen in memory per-request; nothing is embedded or stored.
Develop
node test/serve.js
node test/e2e.js
The e2e suite asserts the signature algorithm against fixed test vectors (fixed input → fixed SHA3-512 / SHA-512 / AES-128 output) and makes a real call to the government NAV test API: a well-formed tokenExchange with placeholder credentials runs the full SHA3-512 signing path and surfaces NAV's native INVALID_SECURITY_USER error — the deepest verification possible without a portal-minted technical user.
Safety
Pure stateless translation layer straight to the government NAV API. The NAV registration and tax context stay with the merchant; credentials travel per-request in headers, nothing is stored or logged. Privacy policy.
Sister servers
National e-invoices: Poland KSeF 2.0 inv-pl · Mexico CFDI 4.0 inv-mx · Chile DTE inv-cl · Brazil NF-e inv-br · Local payments in 81 countries, one family: mcp.wishpool.app · Taiwan e-invoice 電子發票 included.
MIT licensed.