How do I use mcp-ai-fiskalizacija?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-ai-fiskalizacija Napravi račun za konzultacije, 10 sati po 100 EUR, PDV 25%." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

mcp-ai-fiskalizacija

by Seyn-Labs

Overview Schema Related Servers Score Discussions

TypeScript

Remote

mcp-fiskalizacija

MCP (Model Context Protocol) server za izradu i fiskalizaciju računa preko solo.com.hr API-ja.

Daj ovaj MCP bilo kojem AI-ju ili agentu (Claude, Cursor, ChatGPT s MCP podrškom, custom agenti...) i reci mu npr.:

"Napravi mi račun za tvrtku Acme d.o.o., OIB 12345678901, za konzultantske usluge, 10 sati po 80 EUR, PDV 25%, plaćanje na transakcijski račun."

AI će pozvati solo_create_invoice, Solo će dodijeliti sljedeći broj računa, fiskalizirati ga (ZKI/JIR) i vratiti PDF link.

Alati

Alat	Opis
`solo_create_invoice`	Izrađuje i fiskalizira novi račun. Vraća broj računa, iznose, ZKI/JIR i PDF link.
`solo_get_invoice`	Dohvaća jedan račun po ID-u sa svim detaljima.
`solo_list_invoices`	Popis računa (najnoviji prvi, do 1000 po stranici).
`solo_next_invoice_number`	Čita zadnji izdani račun i izračunava sljedeći broj (`redni-prostor-uređaj`, npr. `13-1-1`). Solo broj dodjeljuje automatski pri izradi — alat služi za najavu i provjeru.

Related MCP server: elorus-mcp

Instalacija

git clone <ovaj-repo>
cd mcp-fiskalizacija
npm install
npm run build

Trebаš Solo API token — pronađi ga u Postavkama nakon prijave na solo.com.hr.

Spajanje na AI / agenta

Claude Code

claude mcp add fiskalizacija \
  --env SOLO_API_TOKEN=tvoj-token \
  -- node /putanja/do/mcp-fiskalizacija/dist/index.js

Claude Desktop / bilo koji MCP klijent (JSON config)

{
  "mcpServers": {
    "fiskalizacija": {
      "command": "node",
      "args": ["/putanja/do/mcp-fiskalizacija/dist/index.js"],
      "env": {
        "SOLO_API_TOKEN": "tvoj-token"
      }
    }
  }
}

Cursor

Isti JSON u .cursor/mcp.json u projektu ili globalno u ~/.cursor/mcp.json.

Primjer: kako AI izrađuje račun

Korisnik kaže:

"Napravi račun: kupac Marko Horvat (fizička osoba), usluga 'Izrada web stranice', 1 kom, 500 EUR, PDV 25%, plaćanje karticom."

AI pozove alat ovako:

{
  "tool": "solo_create_invoice",
  "arguments": {
    "tip_kupca": 1,
    "kupac_naziv": "Marko Horvat",
    "usluge": [
      {
        "opis_usluge": "Izrada web stranice",
        "cijena": 500,
        "kolicina": 1,
        "porez_stopa": 25,
        "jed_mjera": "kom"
      }
    ],
    "nacin_placanja": 3
  }
}

Odgovor sadrži:

Račun uspješno kreiran.

Broj računa: 13-1-1
Kupac: Marko Horvat
Neto: 500,00 | Bruto: 625,00 EUR
Način plaćanja: Kartice
ZKI: e4d909c290d0fb1ca068ffaddf22cbd0
JIR (fiskaliziran): 2cf55235-9470-4b5c-a539-463f52b109d2
PDF: https://solo.com.hr/download/...

Obavezne informacije za račun

Minimalno: tip kupca, stavke (opis, cijena, PDV stopa) i način plaćanja.

Za B2B/B2G kupce (tvrtke, javna nabava) dodatno su obavezni naziv kupca, OIB i KPD oznaka po stavci — server to validira prije slanja i vraća jasnu grešku ako nedostaje.

Šifrarnici (Solo API)

Parametar	Vrijednosti
`tip_kupca`	1=B2C fizička osoba, 2=B2B poslovni subjekt, 3=B2G država/javna nabava, 4=EU, 5=INT
`tip_racuna`	1=R1, 2=R2, 3=bez oznake, 4=avansni
`nacin_placanja`	1=transakcijski račun, 2=gotovina, 3=kartice, 4=ček, 5=ostalo
`porez_stopa`	0, 5, 13, 25
`jezik_racuna`	1=hrvatski, 2=engleski, 3=njemački, 4=francuski, 5=talijanski, 6=španjolski
`valuta_racuna`	14=EUR (zadano), 12=USD, 11=GBP, 10=CHF, 6=HUF, 13=BAM, ...
`status`	1=otvoren, 2=poslan, 3=opomenut, 5=plaćen

Kako funkcionira

AI / agent ──(MCP, stdio)──► mcp-fiskalizacija ──(HTTPS)──► api.solo.com.hr ──► Porezna uprava (fiskalizacija)

AI dobije zahtjev korisnika i prikupi obavezne podatke.
Pozove solo_create_invoice (po želji prvo solo_next_invoice_number da najavi broj).
Server validira ulaz (B2B pravila, PDV stope, popusti), pretvori brojeve u Solo format (decimalni zarez) i pošalje form-encoded POST na https://api.solo.com.hr/racun.
Solo dodijeli broj računa, fiskalizira račun (ZKI/JIR) i vrati PDF.
AI korisniku vrati broj računa, iznose i PDF link.

Numeracija: hrvatski broj računa ima oblik redni-poslovniProstor-naplatniUređaj (npr. 13-1-1), a redni broj se resetira svake kalendarske godine — solo_next_invoice_number to uzima u obzir.

Ograničenja Solo API-ja

Plaćeni paket: do 300 računa mjesečno; besplatni: 3 mjesečno.
Fiskalizacija (ZKI/JIR) mora biti uključena u Solo postavkama (certifikat Porezne uprave).
solo_get_invoice koristi Solo ID računa (hex string), ne broj računa.

Razvoj

npm run dev            # pokreni server iz src/ (tsx)
npm test               # testovi (vitest)
npm run test:coverage  # testovi s pokrivenošću
npm run build          # TypeScript build u dist/

Struktura:

src/
  index.ts                  # entry point (stdio transport)
  server.ts                 # MCP server + registracija alata
  solo/
    client.ts               # HTTP klijent za api.solo.com.hr
    serialize.ts            # validacija + form-encoding (decimalni zarez, indeksirane stavke)
    invoice-number.ts       # parsiranje i predviđanje broja računa
    types.ts                # tipovi i šifrarnici
  tools/                    # MCP alati (jedan po datoteci)

Roadmap (2.0)

Više providera fiskalizacije (apsolutna apstrakcija providera iza zajedničkog sučelja)
Storno i brisanje računa (Solo API to podržava)
Ponude (Solo API /ponuda)
Fiskalizacija 2.0 (eRačun B2B obveza od 1.1.2026.)

Licenca

MIT

Available Tools

4 tools

solo_create_invoiceIzradi i fiskaliziraj računA

Izrađuje novi račun preko solo.com.hr servisa. Solo automatski dodjeljuje sljedeći broj računa i fiskalizira ga (ZKI/JIR) ako je fiskalizacija uključena u Solo postavkama. Vraća broj računa, iznose, ZKI/JIR i link na PDF. Za B2B/B2G kupce obavezni su kupac_naziv, kupac_oib i kpd oznaka po stavci.

ParametersJSON Schema

Name	Required	Description
`tip_usluge`	No	ID tipa usluge iz Solo postavki (Usluge nakon prijave). Zadano 1.
`tip_racuna`	No	Tip računa: 1=R1, 2=R2, 3=bez oznake, 4=avansni. Zadano 1 (R1).
`tip_kupca`	Yes	Tip kupca: 1=B2C fizička osoba, 2=B2B poslovni subjekt, 3=B2G država/javna nabava, 4=EU, 5=INT ostatak svijeta
`kupac_naziv`	No	Naziv kupca — OBAVEZNO za tip_kupca 2 (B2B) i 3 (B2G)
`kupac_adresa`	No	Adresa kupca
`kupac_oib`	No	OIB kupca — OBAVEZNO za tip_kupca 2 (B2B) i 3 (B2G)
`usluge`	Yes	Stavke računa (najmanje jedna)
`nacin_placanja`	No	Način plaćanja: 1=transakcijski račun, 2=gotovina, 3=kartice, 4=ček, 5=ostalo. Zadano 1.
`rok_placanja`	No	Rok plaćanja u ISO 8601 formatu (YYYY-MM-DD)
`datum_isporuke`	No	Datum isporuke u ISO 8601 formatu (YYYY-MM-DD)
`napomene`	No	Napomene na računu
`jezik_racuna`	No	Jezik računa: 1=hrvatski (zadano), 2=engleski, 3=njemački, 4=francuski, 5=talijanski, 6=španjolski
`valuta_racuna`	No	Valuta računa: 14=EUR (zadano), 12=USD, 11=GBP, 10=CHF, ...
`tecaj`	No	Tečaj prema EUR (EUR=1), do 6 decimala
`iban`	No	Odabir računa za uplatu: 1 ili 2 (iz Solo postavki)
`status`	No	Status računa: 1=otvoren (zadano), 2=poslan, 3=opomenut, 5=plaćen

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses automatic number assignment, fiscalization, and return values (number, amounts, ZKI/JIR, PDF link). Without annotations, it covers key behaviors but omits side effects or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise, no wasted words. Front-loaded with purpose, then automatic behaviors, return values, and special requirements. All sentences are substantive.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, key behaviors, return values, and conditional constraints. With no output schema, description adequately explains what is returned. Could mention more about parameter combinations (e.g., when tip_racuna matters), but sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. Description adds value by consolidating conditional requirements (B2B/B2G: kupac_naziv, kupac_oib, kpd) into a single sentence, aiding understanding beyond individual parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool creates an invoice via Solo service, with automatic numbering and fiscalization. It distinguishes from sibling tools (get, list, next number) by being the only creation tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies use for creating invoices, and includes specific requirements for B2B/B2G customers. Lacks explicit exclusion of siblings, but context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

solo_get_invoicePrikaži računA

Dohvaća pojedinačni račun sa solo.com.hr po njegovom ID-u (heksadecimalni identifikator, ne broj računa). Vraća sve detalje računa uključujući stavke, iznose, ZKI/JIR i PDF link.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	ID računa (hex identifikator iz Solo sustava)

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description explains it returns all details including items, amounts, ZKI/JIR, and PDF link, giving clear behavioral expectations. Could be improved by noting if any restrictions (e.g., auth) exist, but sufficient for a simple retrieval.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no redundancy. Front-loaded with verb and resource, then details. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, description sufficiently describes return content (items, amounts, ZKI/JIR, PDF link). Siblings are distinct (create, list, next number), no missing context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. Description adds value by clarifying that the 'id' parameter is a hex identifier from the Solo system, not the invoice number, which addresses a common confusion.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves a single invoice by its ID, using specific verb 'Dohvaća' (retrieves) and resource 'račun' (invoice). It distinguishes from siblings by specifying it retrieves by ID and returns details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage by specifying the ID format (hex identifier, not invoice number) to avoid confusion, but does not explicitly state when to use this tool vs alternatives or provide exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

solo_list_invoicesPopis računaA

Dohvaća popis računa sa solo.com.hr (najnoviji prvi, do 1000 po stranici). Vraća broj računa, datum, bruto iznos i status za svaki račun.

ParametersJSON Schema

Name	Required	Description	Default
`stranica`	No	Broj stranice ako postoji više od 1000 računa
`limit`	No	Koliko računa vratiti u odgovoru (zadano 20)

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but the description discloses ordering (newest first), maximum page size (1000), and the fields returned (invoice number, date, gross amount, status). This adds behavioral context beyond the input schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose and key behaviors. Every sentence is informative and no waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description adequately covers ordering, pagination, and returned fields for a list tool. No output schema, but fields are listed. Minor improvement could mention total count or filtering, but current level is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. The description reinforces pagination behavior and limit but does not add significant parameter semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies the verb 'Dohvaća' (retrieves) and the resource 'popis računa' (list of invoices), and includes ordering (newest first) and pagination limit. It clearly distinguishes from siblings: solo_create_invoice, solo_get_invoice, and solo_next_invoice_number.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states the ordering and maximum results per page, providing context for usage. However, it does not explicitly mention when to use this tool versus alternatives, though sibling names hint at differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

solo_next_invoice_numberSljedeći broj računaA

Dohvaća zadnji izdani račun sa solo.com.hr i izračunava sljedeći broj računa (redni broj + 1, format 'broj-poslovniProstor-uređaj', resetira se svake godine). Korisno za najavu broja prije izrade računa — napomena: Solo pri izradi računa sam dodjeljuje broj, pa ovaj alat služi za informaciju i provjeru.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavior: fetching last invoice (read), computing next number, format, yearly reset, and warning that actual number may differ. This is comprehensive and transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single clear sentence with a concise note; no redundant information. It is well-structured and front-loaded with key action and output.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description explains the output format and behavior, but it does not explicitly state the data type (string/object). Slightly more detail on return structure would improve completeness, but sufficient for the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so schema coverage is 100%. The description adds value by explaining the return format and context, going beyond the schema. Baseline for 0 params is 4, and the description exceeds it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool fetches the last invoice and computes the next number, specifying the format and reset behavior. It is distinct from sibling tools (create, get, list) which focus on different operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains it is useful for announcing the number before creating an invoice and notes that Solo assigns its own number, indicating the tool is for information/verification. It could explicitly mention when not to use, but the context provides clear guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: create, get by ID, list, and retrieve next invoice number. There is no overlap in functionality.

Naming Consistency4/5

All tools use the 'solo_' prefix and snake_case, but 'solo_next_invoice_number' is a noun phrase rather than a verb+noun pattern, introducing a minor inconsistency.

Tool Count4/5

4 tools cover the core operations for an invoice management server (create, read, list, and a utility). The count is reasonable, though slightly small for a full lifecycle.

Completeness3/5

The tool set provides create, get, list, and next number, but lacks update and delete/cancel functionality, which are notable gaps for invoice management.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

invoice-badger
com.invoicebadger
Invoicing you drive by talking to your AI: log time, raise invoices and track what's owed via MCP.
Finance Payments & Billing
2
Mini Accountant
app.miniaccountant
Hosted MCP server for Mini Accountant: invoices, expenses, customers, analytics, tax estimates.
E-commerce & Retail Finance ERP Systems
1
Artificial Wit AI
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
Fakto.app — Fakturownia MCP Server
app.fakto
Fakturownia.pl (Polish invoicing) via MCP: invoices, clients, products, warehouse. Full read-write.
Finance Payments & Billing ERP Systems
1

Related MCP Servers

invoiceninja-mcp
Finance CRM Payments & Billing
ambaloo
A
license
B
quality
F
maintenance
MCP server for Invoice Ninja v5 API. Enables AI assistants to manage clients, invoices, quotes, payments, and time tracking through natural language.
Updated 7 months ago (2026-01-23 14:26 UTC)
32
22
2
MIT
elorus-mcp
Finance Payments & Billing
nikan
A
license
A
quality
B
maintenance
MCP server for the Elorus invoicing and accounting platform, enabling AI assistants to create invoices, manage contacts, and query financial data through natural language.
Updated 2 months ago (2026-07-03 17:21 UTC)
43
3
MIT
SuperFaktura MCP Server
Finance CRM Payments & Billing
jurajgh
A
license
Not graded
quality
D
maintenance
Model Context Protocol (MCP) server for SuperFaktura invoicing system. Enables AI assistants to interact with SuperFaktura API for managing invoices, clients, and expenses.
Updated 2 months ago (2026-07-09 14:37 UTC)
Apache 2.0
brazil-invoice-mcp
Payments & Billing Finance
junter1989k-ai
A
license
Not graded
quality
B
maintenance
MCP server that lets AI agents issue Brazilian NFS-e service invoices via Focus NFe, with tools for creating, querying, and canceling invoices.
Updated 2 months ago (2026-07-11 05:45 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Seyn-Labs/mcp-ai-fiskalizacija'

If you have feedback or need assistance with the MCP directory API, please join our Discord server