mcp-fattura-elettronica-it

Build Dati Pagamento

build_dati_pagamento

Build the DatiPagamento block for Italian e-invoices, validating payment terms, method, IBAN, and due date. Place it between totals and XML generation to ensure compliant payment data.

Instructions

Build the DatiPagamento block for the FatturaElettronicaBody.

Use this as step 9 in the invoice generation workflow, after compute_totali() and before generate_fattura_xml(). The block is optional in the XML but strongly recommended for B2B invoices.

condizioni_pagamento: TP01 = instalments, TP02 = single full payment, TP03 = advance. modalita_pagamento: MP05 (bank transfer) is most common for B2B; include iban when using MP05. importo_pagamento: for TP02 this should equal totale_fattura from compute_totali(); for TP01 (instalments) call this tool once per instalment tranche.

Validates: condizioni_pagamento in {TP01, TP02, TP03}; modalita_pagamento in MP01–MP23; IBAN format (letters + digits, max 34 chars); data_scadenza_pagamento is YYYY-MM-DD.

On success returns {'DatiPagamento': {...}} ready for generate_fattura_xml(). On failure returns {'error': ''}.

Input Schema

TableJSON Schema

Name	Required	Description
`iban`	No	IBAN for bank transfer (MP05). Validated for format (letters+digits, max 34 chars).
`importo_pagamento`	Yes	Payment amount (may equal or differ from invoice total for instalments).
`modalita_pagamento`	Yes	Payment method code MP01–MP23. Common values: MP05 (bonifico/bank transfer), MP01 (cash), MP08 (card), MP19/MP20/MP21 (SEPA direct debit), MP23 (PagoPA). Use a valid MP code from the FatturaPA reference.
`condizioni_pagamento`	Yes	Payment terms code: 'TP01' = full payment in instalments, 'TP02' = full single payment, 'TP03' = advance payment.
`istituto_finanziario`	No	Name of the financial institution (bank name). Optional.
`data_scadenza_pagamento`	No	Payment due date (YYYY-MM-DD). Omit for immediate payment.

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.7/5.0

Behavior4/5

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

No annotations exist, so the description carries the burden. It does well: states validation rules, success/error return shape, and the pure 'build' nature. It doesn't explicitly say there are no side effects or that it is idempotent, but the return-value description makes a pure-builder behavior clear enough.

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

Conciseness4/5

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

Purpose is front-loaded and the workflow/validation/return details are organized in short paragraphs. Slightly long, but every sentence contributes semantic value; the validation list is dense but useful.

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?

For a 5-param builder with no output schema warning, the description is complete: it states positioning in the workflow, conditional parameter semantics, validation rules, and both success/error return shapes. An agent has everything needed to invoke it correctly without external knowledge.

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?

Schema only lists bare codes and types; the description adds real meaning: TP01/TP02/TP03 semantics, MP05 as the common B2B method, IBAN requirement for MP05, instalment usage per tranche, and the relationship between importo_pagamento and invoice total. This is exactly what an agent needs to fill the parameters correctly.

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?

Opens with a specific verb and object ('Build the DatiPagamento block for the FatturaElettronicaBody') and immediately anchors it in the workflow ('step 9... after compute_totali, before generate_fattura_xml'). No ambiguity about what this tool does or where it fits.

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?

Gives clear positional context in the pipelinecomputing and explicit when/why to use it: optional but recommended for B2B, call once per instalment tranche for TP01, and 'when to use' nuance for payment methods and IBAN. This is actionable guidance beyond the schema.

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

Deploy Server