Hungary Invoices (NAV Online Szamla 3.0 reporting API)
Server Details
Hungary NAV Online Szamla 3.0 invoice reporting for AI agents: report invoice data, query status.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 2 of 2 tools scored.
The two tools have clearly distinct purposes: one submits invoice data, the other queries processing status. There is no overlap or ambiguity.
Both tools follow a consistent verb_noun pattern: submit_invoice and query_transaction, making their roles immediately clear.
With only 2 tools, the server is minimal but well-scoped for its narrow purpose of invoice data reporting. A few more tools (e.g., for cancellation or listing) would improve completeness but the count is not unreasonable.
The server covers the core submit-and-check workflow, but lacks tools for cancellation, listing past transactions, or managing technical users, which are common needs in this domain.
Available Tools
2 toolsquery_transactionARead-onlyInspect
Check the NAV processing status of an invoice-data submission by its transactionId (returned by submit_invoice). Status values (per invoice index): RECEIVED (NAV received it), PROCESSING (validating), SAVED (stored — non-fatal warnings possible), DONE (successfully processed and stored — this is the success terminal), ABORTED (rejected — read validation_messages for the reason). Authenticates with your technical-user keys; safe to call anytime.
| Name | Required | Description | Default |
|---|---|---|---|
| transaction_id | Yes | The transactionId returned by submit_invoice. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as readOnlyHint and openWorldHint. The description adds authentication details, safety to call anytime, and a detailed breakdown of status values, which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that efficiently packs purpose, usage, status details, and authentication info. It could be slightly more concise, but it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description compensates by listing all possible status values and their meanings, including what to look for in fallback fields (validation_messages). This makes the tool's behavior fully predictable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage and a single parameter, the schema already describes the parameter well. The description adds minimal extra context ('by its transactionId') but doesn't significantly improve understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks NAV processing status of an invoice-data submission by transactionId, and explicitly distinguishes from the sibling tool submit_invoice by referencing the transactionId returned by it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says to use it after submit_invoice and provides status values and their meanings. It doesn't explicitly state when not to use it, but the context is clear given the single sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_invoiceAInspect
Report a Hungary invoice to NAV Online Számla 3.0 (számla adatszolgáltatás) — the national invoice-data reporting API of the Hungarian tax authority (NAV). This is REPORTING, not issuing: the merchant issues the actual invoice to the buyer; this tool submits the invoice data to NAV as legally required and returns a transactionId. Bring your own technical-user credentials via headers, all self-minted in the Online Számla web portal (onlineszamla.nav.gov.hu -> Technical users): x-nav-login, x-nav-password, x-nav-signkey, x-nav-exchangekey, x-nav-taxnumber (your 8-digit tax number). Runs against the NAV TEST environment by default (no legal effect); set header x-nav-mode: prod to report real invoices. The server exchanges a token, builds the InvoiceData XML, signs the request (SHA3-512), submits a CREATE operation, and returns the transactionId — then call query_transaction to read the processing result. Amounts are in HUF; each line carries a NET unit price and a Hungarian ÁFA (VAT) rate (27, 18, 5, or 0) — the server computes per-rate net/VAT and the invoice gross total.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | Line items. Each: name, quantity, unit_net_price (HUF, per unit, NET/excl. VAT), vat_rate (27, 18, 5, or 0). | |
| currency | No | ISO currency code. Default HUF (only HUF is supported in v0.1). | |
| issue_date | No | Invoice issue date (kelt) YYYY-MM-DD. Defaults to today (UTC). | |
| customer_city | No | Buyer address city (default Budapest). | |
| customer_name | Yes | Buyer legal name (or private person name). | |
| delivery_date | No | Fulfilment date (teljesítés) YYYY-MM-DD. Defaults to the issue date. | |
| supplier_city | No | Supplier address city (default Budapest). | |
| supplier_name | Yes | Supplier (seller) legal name — your company. The supplier tax number comes from the x-nav-taxnumber header. | |
| invoice_number | Yes | Your invoice number (számlaszám) exactly as issued to the buyer, e.g. 2026/00123. | |
| payment_method | No | Payment method. Default TRANSFER. | |
| customer_tax_number | No | Buyer Hungarian tax number for B2B: 8 digits (core) or 11 digits (core+vatCode+countyCode, e.g. 12345678-2-41). Omit for a private person (customerVatStatus becomes PRIVATE_PERSON). | |
| customer_postal_code | No | Buyer address postal code (default 0000). | |
| supplier_postal_code | No | Supplier address postal code (default 0000). | |
| customer_address_line | No | Buyer street address line (default "-"). | |
| supplier_address_line | No | Supplier street address line (default "-"). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides extensive behavioral details beyond annotations: it interacts with an external API, requires specific headers, performs token exchange, XML building, SHA3-512 signing, returns transactionId, and defaults to test environment. Annotations already indicate non-destructive/non-readonly, so the description adds considerable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured, starting with the main purpose, then important clarifications (reporting not issuing), headers, environment, process, and return value. It front-loads key information, though some sentences could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 15 parameters, external API, legal context, and no output schema, the description covers prerequisites, environment, internal process, return value, and sibling tool. It is thorough for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying amounts are in HUF, vat rate meanings, and customer_tax_number behavior for B2B vs. private person, which goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports Hungary invoices to NAV Online Számla 3.0, highlighting it is for reporting, not issuing. It distinguishes from the sibling query_transaction by explaining the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (legally required reporting) and specifies test vs. prod environment via headers. It mentions calling query_transaction afterward but does not explicitly exclude other alternatives, though only one sibling exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!