billingo-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | Port the HTTP server listens on. | 3000 |
| BILLINGO_API_KEY | Yes | Your Billingo API key. | |
| BILLINGO_BASE_URL | No | Override the API base URL, e.g. to point at a proxy. | https://api.billingo.hu/v3 |
| BILLINGO_ALLOW_WRITE | No | Set to "true" or "1" to enable write tools for this stdio process. Any other value is treated as false. | false |
| BILLINGO_ALLOWED_HOSTS | No | Comma-separated list of Host header values the server will accept. Set whenever the server is reachable from outside localhost. |
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 |
|---|---|
| billingo_get_organizationA | Returns account-level data for the organization that owns the API key: its tax code, its Billingo subscription, and whether NAV Online Számla is connected. This is NOT a company profile — it contains no name, id or address. Use it to check the subscription or NAV connection status. |
| billingo_check_tax_numberA | Looks up a Hungarian tax number at NAV and returns the company data behind it. Use this to validate a tax number before creating a partner. Works only when the Billingo account has a live NAV Online Számla connection (not available on sandbox accounts). |
| billingo_get_conversion_rateB | Returns the conversion rate Billingo would apply between two currencies. |
| billingo_list_partnersA | Lists partners (customers), newest first. Supports paging and a free-text search over the partner name. |
| billingo_get_partnerB | Returns a single partner by id. |
| billingo_list_productsB | Lists products and services from the product catalogue. |
| billingo_get_productA | Returns a single product by id. |
| billingo_get_product_quantityA | Returns the current inventory quantity for a product. |
| billingo_list_spendingsA | Lists recorded spendings (costs), optionally filtered by date range. |
| billingo_get_spendingB | Returns a single spending by id. |
| billingo_list_bank_accountsB | Lists the bank accounts configured on the organization. |
| billingo_get_bank_accountA | Returns a single bank account by id. |
| billingo_list_document_blocksA | Lists document blocks (invoice number ranges). Every document belongs to a block; you need a block id to create an invoice. |
| billingo_list_documentsA | Lists documents (invoices, receipts, proformas, drafts and more), newest first. Filter by type, invoice date range, fulfillment date range, payment date range, last modification time, partner, payment status/method or document block. |
| billingo_get_documentA | Returns a single document. Give either |
| billingo_download_documentA | Gets the document PDF. By default returns a shareable public URL — this is what works in most MCP clients (including Claude Desktop, which rejects the base64 file attachment) and is what you want in almost every case. Pass format="base64" only when a caller specifically needs the raw PDF bytes: it costs a lot of context (base64 is ~1.33x the PDF size) and some clients cannot render the result at all. |
| billingo_get_document_public_urlA | Returns a shareable public URL for the document, viewable without a Billingo login. |
| billingo_get_online_szamla_statusA | Returns the NAV Online Számla reporting status of a document: the transaction id, the status, and any validation messages from NAV. Use this to check whether reporting succeeded. Errors (4xx, "NavOnlineSzamla is not found") when the document has no NAV record at all — for example when the organization is not connected to NAV Online Számla, or the document is not subject to reporting. That is not a NAV failure; it means there is nothing to report on. |
| billingo_get_document_paymentsB | Returns the payments recorded against a document. |
| billingo_get_document_remindersB | Returns the payment reminder events sent for a document, grouped into sent, upcoming and postal-mail reminders. |
| billingo_pos_printA | Returns a printable PDF receipt for a document, sized for a POS thermal printer. |
| billingo_export_documentsA | Exports documents in a date range to a downloadable file, in one of the accounting/reporting formats Billingo supports (e.g. simple_csv, simple_excel, or a named accounting-system format). Creates the export, waits for it to finish, and returns the file. Nothing is modified. Textual formats (simple_csv, nav_xml, and other XML/JSON-based targets) come back as readable text you can analyse directly — very large exports are truncated with an explicit note, and a narrower date range will return the whole thing. Binary formats (simple_excel, simple_excel_items) come back as a file attachment that some MCP clients cannot display inline. |
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 22 tools
Most tools target a clearly distinct resource and action (list vs get for partners, products, spendings, bank accounts; document-specific operations like payments, reminders, NAV status, POS print). The main overlap is billingo_download_document vs billingo_get_document_public_url, which both default to returning a shareable public URL, making selection ambiguous.
Names follow a consistent billingo_ prefix with snake_case verb_noun structure (list_documents, get_partner, export_documents, check_tax_number). Minor deviation: billingo_pos_print uses noun_verb ordering rather than the verb_noun pattern used elsewhere.
22 tools is on the heavy side for the rubric, though the broad billing domain (documents, partners, products, spendings, org, bank accounts) partly justifies it. Several simple list/get pairs could potentially be consolidated, placing it at borderline.
The surface is almost entirely read-only: there are no create/update/delete tools for invoices, partners, products, or spendings, yet descriptions reference creating partners and needing block ids to create invoices, implying write operations that don't exist. Core billing workflows (issuing an invoice, recording a payment) cannot be performed, a significant gap.