Serbia Invoices (SEF eFaktura national API)
Server Details
Serbia SEF eFaktura invoices for AI agents: build UBL 2.1 SRB-CIUS, upload to SEF, query, cancel.
- Status
- Unhealthy
- 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.6/5 across 3 of 3 tools scored.
Each tool has a distinct purpose: creating invoices, canceling them before buyer action, and querying their status. There is no overlap or ambiguity.
All tools follow the consistent verb_noun pattern (cancel_invoice, create_invoice, query_invoice), making them predictable and easy to understand.
With only 3 tools, the server is minimal but covers the core operations for the stated scope (v1, seller-side). Slightly thin, but reasonable for a focused API.
The tools cover create, cancel, and query, but missing listing invoices or retrieving full invoice details. Storno (credit note) is out of scope, but the absence of a list/get function is a notable gap.
Available Tools
3 toolscancel_invoiceADestructiveInspect
Cancel (Otkazivanje) a Serbia sales invoice you sent, using its sales_invoice_id and a mandatory reason (cancel_comment). This is the seller cancelling their own Sent invoice before the buyer accepts or rejects it; once the buyer has Approved it, cancellation is no longer possible and a storno (credit) document is required instead (storno is out of scope in v1 — honest limit). Returns the SEF response. Irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| cancel_comment | Yes | Reason for cancellation (razlog otkazivanja). Required by SEF. | |
| sales_invoice_id | Yes | The sales_invoice_id returned by create_invoice. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true (irreversible), and description confirms 'Irreversible.' Adds context about the invoice state machine (Sent vs Approved) and that it returns the SEF response, going 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?
Three sentences with no fluff, front-loaded with key information. Every sentence adds value.
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 the tool's simplicity (2 params, no output schema), the description fully covers purpose, usage, behavior, and parameters. In context of siblings, it is complete.
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 covers both parameters (100% coverage). Description adds that cancel_comment is a mandatory reason and that sales_invoice_id comes from create_invoice, providing context beyond the schema.
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 action: cancel a Serbia sales invoice using sales_invoice_id and cancel_comment. It specifies the context (seller cancelling own Sent invoice before buyer action) and distinguishes from siblings create_invoice and query_invoice.
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?
Explicitly states when to use (before buyer accepts/rejects) and when not (after buyer approved, need storno). Mentions storno is out of scope, providing clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_invoiceAInspect
Issue a Serbia B2B electronic invoice (elektronska faktura) into the national SEF eFaktura system (Ministry of Finance). Builds UBL 2.1 XML in the SRB-CIUS customization (Serbia's CIUS of EN 16931) and uploads it under your own SEF API key. Bring your own credential as a header: x-sef-api-key (the API key you self-generate in the SEF portal under Settings -> API management / Podesavanja -> Upravljanje API). Header x-sef-mode: prod switches to the live rail (default = demo, no fiscal effect). You must supply your own seller identity in the arguments (supplier_pib + supplier_name), because SEF validates that the seller in the XML matches your account. Returns sales_invoice_id (SEF's invoice id) — poll query_invoice with it to learn the status (New/Sent/Approved/Rejected/Cancelled...). Serbian VAT rates: 20 (standard), 10 (reduced), 0 (zero-rated). Amounts are in RSD (Serbian dinar). Set send_to_cir=true when the buyer is a budget / public-sector user (registration in the Central Invoice Register / CRF is then mandatory).
| Name | Required | Description | Default |
|---|---|---|---|
| lines | Yes | Invoice lines. Each: name, unit_price (net, VAT-exclusive, RSD), vat_rate (20|10|0), optional quantity (default 1) and unit_code (UN/ECE Rec 20, default C62 = piece). | |
| currency | No | Document currency (BT-5). Default RSD. | |
| due_date | No | Optional payment due date (BT-9), YYYY-MM-DD. | |
| issue_date | No | Invoice issue date (BT-2), YYYY-MM-DD. Default: today (UTC). | |
| send_to_cir | No | Send to the Central Invoice Register (CRF). Set true when the buyer is a budget / public-sector user; default false for private B2B. | |
| customer_pib | Yes | Buyer PIB / tax number, exactly 9 digits. | |
| supplier_pib | Yes | Your (seller) PIB / tax number (poreski identifikacioni broj), exactly 9 digits. Required — SEF validates it against your API-key account. | |
| customer_city | No | Buyer city (BT-52). Default Beograd. | |
| customer_name | Yes | Buyer legal name (naziv) as registered. | |
| supplier_city | No | Your (seller) city (BT-37). Default Beograd. | |
| supplier_name | Yes | Your (seller) legal name (BT-27). Required for a valid invoice. | |
| invoice_number | No | Your invoice number (BT-1). Auto-generated if omitted. | |
| customer_address | Yes | Buyer street address (BT-50 address line 1). | |
| customer_country | No | Buyer country code (BT-55). Default RS. | |
| supplier_address | No | Your (seller) street address (BT-35). Recommended. | |
| customer_registration_number | No | Buyer company registration number (maticni broj), 8 digits (BT-47). Recommended. | |
| supplier_registration_number | No | Your (seller) company registration number (maticni broj), 8 digits (BT-30). Recommended. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses authentication via header, return of sales_invoice_id, polling recommendation, VAT rates, and currency. No contradictions, and it adds substantial behavioral 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 long but well-structured, front-loading the purpose and then logically covering authentication, requirements, return behavior, and usage nuances. Every sentence provides value; however, slight reduction could improve conciseness.
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 the parameter count (17) and no output schema, the description covers authentication, return value, follow-up process, VAT rates, and special cases like send_to_cir. It lacks error handling details but is otherwise complete 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 explaining overarching context (e.g., supplier_pib validation, send_to_cir rationale, VAT rates) that goes beyond individual parameter 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's specific verb 'Issue' and resource 'Serbia B2B electronic invoice into the national SEF eFaktura system', distinguishing it from sibling tools cancel_invoice and query_invoice by indicating its unique purpose.
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 provides explicit context for when to use this tool, such as mentioning polling query_invoice for status and setting send_to_cir for public-sector buyers. It implicitly distinguishes from siblings but does not explicitly list when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_invoiceARead-onlyInspect
Check the SEF status of a sales invoice created by create_invoice, using its sales_invoice_id. Status values (SEF SalesInvoiceStatus): NEW (Nova/New — draft not yet sent); SENDING (in transit); SENT (delivered to the buyer, awaiting their action); SEEN (buyer opened it); APPROVED (buyer accepted — Prihvacena); APPROVED_WITH_RESERVATION (accepted with reservation); REJECTED (buyer rejected — Odbijena); CANCELLED (seller cancelled — Otkazana); STORNO (reversed by a storno document); MISTAKE (marked as an error); OVERDUE (payment past due); REMINDED (a reminder was sent); DELETED. Safe to call anytime.
| Name | Required | Description | Default |
|---|---|---|---|
| sales_invoice_id | Yes | The sales_invoice_id returned by create_invoice. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond annotations: lists all 12 status values with translations and states 'Safe to call anytime'. Annotations already indicate readOnlyHint=true, but description enriches transparency.
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?
Concise, front-loaded with purpose, includes a list of status values. Every sentence adds value, no waste.
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?
Despite no output schema, description fully explains return values (status enum). Covers input, purpose, output, and safety. Complete for a query tool.
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 covers 100% of parameters (sales_invoice_id). Description adds meaning by specifying it must be from create_invoice, clarifying origin beyond schema.
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?
Description clearly states verb 'check', resource 'SEF status of a sales invoice', and scope 'using its sales_invoice_id'. It distinguishes from siblings cancel_invoice and create_invoice.
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?
Explicitly says to use for checking status and requires sales_invoice_id from create_invoice. Does not explicitly state when not to use or alternatives, but context is clear.
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!