Skip to main content
Glama
cmendezs

mcp-fattura-elettronica-it

add_linea_dettaglio

Add a single line item to an Italian e-invoice, specifying VAT rate, exemption nature, pricing, quantity, and optional data for XML generation.

Instructions

Build a single DettaglioLinee (line item) entry for the FatturaElettronicaBody.

Use this as step 7 in the invoice generation workflow — call once per line item after build_dati_generali(). Collect all returned dicts into a list and pass it to compute_totali() (step 8) and then generate_fattura_xml() (step 10).

numero_linea must be sequential starting at 1; do not reuse numbers in the same invoice. prezzo_totale must be provided explicitly (not computed); use negative values for credit notes. When aliquota_iva is 0.0, natura is required — call get_natura_codes() to select the code. Set ritenuta='SI' on lines subject to withholding tax and include the DatiRitenuta block from check_ritenuta_acconto() when generating XML. altri_dati_gestionali (optional): structured management data entries, emitted after Natura in the XSD element order. See build_sport_worker_exemption_dato_gestionale() for the codifica introduced by Specifiche Tecniche 1.9.1.

On success returns {'DettaglioLinee': {...}}, plus 'warnings' (list[str]) when aliquota_iva is a non-standard IT VAT rate (outside 4, 5, 10, 22). On failure returns {'error': ''}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
naturaNoNatura exemption code: N1, N2.1, N2.2, N3.1–N3.6, N4, N5, N6.1–N6.9, N7. Parent codes N2, N3, N6 are invalid since Jan 2021 and are not accepted. Required when aliquota_iva is 0.0. Use get_natura_codes() for the full list.
quantitaNoQuantity (Quantita). Optional for services billed as a lump sum. When provided, unit_price × quantita should equal prezzo_totale.
ritenutaNoWithholding tax flag: 'SI' to indicate that this line is subject to ritenuta d'acconto. Use check_ritenuta_acconto() to compute the amount.
descrizioneYesDescription of the good or service (max 1000 chars).
aliquota_ivaNoVAT rate as a percentage (e.g. 22.0 for 22%, 10.0 for 10%, 0.0 for exempt). Use 0.0 together with a Natura code for exempt/out-of-scope supplies.
numero_lineaYesSequential line number starting at 1. Each DettaglioLinee entry must have a unique NumeroLinea.
unita_misuraNoUnit of measure (e.g. 'PZ', 'KG', 'ORE', 'M2'). Optional.
prezzo_totaleNoTotal line amount before VAT (PrezzoTotale = quantita × prezzo_unitario). Must be provided explicitly; the tool does not auto-compute it.
prezzo_unitarioNoUnit price before VAT (PrezzoUnitario). Negative for credit notes.
altri_dati_gestionaliNoOptional list of AltriDatiGestionali entries (DettaglioLinee, XSD maxOccurs unbounded). Each entry is a dict with XSD-cased keys: 'TipoDato' (str, required, max 10 chars), 'RiferimentoTesto' (str, optional, max 60 chars), 'RiferimentoNumero' (str/float, optional), 'RiferimentoData' (str YYYY-MM-DD, optional) — the same shape returned by build_sport_worker_exemption_dato_gestionale()['AltriDatiGestionali'], which can be passed straight through in this list for the sport-worker IRPEF exemption codifica ('ESENZSPORT').

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Install Server

TDQS

A4.9/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly documents success return values, the warnings behavior for non-standard VAT rates, and the error contract {'error': '<reason>'}. It also exposes workflow-relevant behavior: prezzo_totale is not auto-computed and line numbers must be sequential and unique.

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 dense but well-organized: starting with purpose, moving to workflow position, then conditional parameter rules, and finally return/error contracts. Every paragraph earns its place, and the structure allows an agent to quickly extract the most important call constraints without wading through filler.

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 the tool's complexity (10 parameters, no annotations, part of a larger workflow), the description covers calling order, per-line repeat usage, edge cases like exempt VAT and withholding tax, optional structured data, and both success and failure return shapes. There is no obvious missing information an agent would need to call it correctly.

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 description coverage is already 100%, so the baseline is 3. The description adds meaningful extra semantics beyond the schema: sequential numero_linea enforcement, explicit prezzo_totale requirement, negative values for credit notes, warning on non-standard aliquota_iva, and the XSD ordering of altri_dati_gestionali. This is more than redundant schema restatement, but some of the prose overlaps with existing 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?

The description opens with a specific verb and resource: 'Build a single DettaglioLinee (line item) entry for the FatturaElettronicaBody.' It also positions the tool as step 7 in the invoice generation workflow, which makes its role unambiguous among the many sibling build_* helpers.

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

Usage Guidelines5/5

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

The description gives explicit workflow guidance: call once per line item, after build_dati_generali(), and pass collected results to compute_totali() and generate_fattura_xml(). It also provides when-to-use conditions for natura, ritenuta, credit notes, and optional altri_dati_gestionali, so an agent knows exactly when each behavior applies.

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

Other Tools

Latest Blog Posts

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/cmendezs/mcp-fattura-elettronica-it'

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