mcp-fattura-elettronica-it

Compute Totali

compute_totali

Compute VAT summary totals (DatiRiepilogo) grouped by tax rate and nature from raw line values, returning imponibile, imposta, and total invoice amount for Italian e-invoicing.

Instructions

Compute DatiRiepilogo VAT summary totals grouped by AliquotaIVA and Natura.

Use this as step 8 in the invoice generation workflow, after all add_linea_dettaglio() calls and before generate_fattura_xml(). Pass the raw line values (not the DettaglioLinee dicts): each item needs 'prezzo_totale' (float), 'aliquota_iva' (float), and optionally 'natura' (str).

Groups lines by (aliquota_iva, natura) pair, sums imponibile, and computes imposta = imponibile × aliquota / 100 (rounded HALF_UP to 2 decimal places). EsigibilitaIVA defaults to 'I' (immediata) for all groups.

Always succeeds (empty list produces empty DatiRiepilogo). Returns: {'DatiRiepilogo': [...], 'totale_imponibile': str, 'totale_imposta': str, 'totale_fattura': str}. Pass 'DatiRiepilogo' directly to generate_fattura_xml() as dati_riepilogo.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`linee`	Yes	List of line item dicts, each containing at least: 'prezzo_totale' (float), 'aliquota_iva' (float), and optionally 'natura' (str). These are the raw values, not the DettaglioLinee dicts.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Apr 28, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations, the description carries the full burden, and it delivers: discloses grouping logic, rounding method (HALF_UP to 2 decimals), default EsigibilitaIVA value, behavior on empty input (always succeeds), and the exact return structure. It also warns against passing DettaglioLinee dicts, adding important edge-case transparency.

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 front-loaded with the core purpose, then logically covers usage, calculation, defaults, and return. Every sentence conveys necessary information without redundancy or filler. The structure flows naturally from what → when → how → what to expect.

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 algorithmic complexity and the presence of an output schema (not shown here but indicated by context), the description is thorough. It details the grouping, calculation, rounding, default value, empty-list behavior, and the exact return keys, plus how to feed the result into generate_fattura_xml(). Nothing an agent needs to invoke it correctly is missing.

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 100%, so the baseline is 3. The description adds value by explaining how each field is used (prezzo_totale, aliquota_iva, natura) beyond the schema's type declarations, and clarifies the expected input is raw values rather than dicts. This is helpful but not radically new information beyond what the schema already states.

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 states a specific verb (compute) and resource (DatiRiepilogo VAT summary totals), and precisely defines the grouping keys (AliquotaIVA and Natura). It clearly distinguishes itself from sibling tools like add_linea_dettaglio and generate_fattura_xml by describing its specific role in the workflow and the transformation it performs.

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?

Explicitly instructs when to use the tool: step 8 in the invoice generation workflow, after add_linea_dettaglio() and before generate_fattura_xml(). It also clarifies the input format (raw line values, not DettaglioLinee dicts), leaving no ambiguity about when and how to call it.

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

Deploy Server