Loading ToolBench
MCP server for Italian e-invoicing — FatturaPA XML / SDI, direct-to-SdI, no intermediary
Mixed quality across 14 tools. Strengths: all tools have descriptions (10 - 500+ chars); most parameters have type definitions and descriptions; Italian domain expertise evident in detailed parameter guidance (e.g., build_dati_generali's extensive TD code and fiscal regime documentation). Weaknesses: tool naming inconsistency (it__ prefix on some, not others); several tools lack output schema documentation; error handling guidance sparse; some parameter descriptions are verbose but lack actionable constraints (enums, ranges); no tool annotations (readOnlyHint, destructiveHint) despite clear risk levels (WRITE, IRREVERSIBLE, READ_ONLY).
Build the DatiGenerali block required in every FatturaElettronicaBody. Use this as step 6 in the invoice generation workflow, after validate_cessionario() and before add_linea_dettaglio(). Call get_tipo_documento_codes() first to select the correct TD code (most invoices use TD01; credit notes use TD04; professional fee invoices use TD06). For credit notes (TD04) or debit notes (TD05), set id_documento_riferimento to the original invoice number and data_documento_riferimento to its issue date. Validates: tipo_documento must be a valid TD01–TD28 code; data must be YYYY-MM-DD; numero must not exceed 20 characters. On success returns {'DatiGenerali': {...}} ready for generate_fattura_xml(). On failure returns {'error': '<reason>'}.
Build the DatiTrasmissione block required in every FatturaPA header. Use this as step 3 in the invoice generation workflow, after generate_progressivo_invio() and before validate_cedente_prestatore(). Use lookup_codice_destinatario() first to confirm the recipient code format. Validates: formato_trasmissione must be 'FPA12' or 'FPR12'; progressivo_invio must be 1–10 alphanumeric characters; pec_destinatario is required when codice_destinatario is '0000000'. On success returns {'DatiTrasmissione': {...}} ready to pass to generate_fattura_xml(). On failure returns {'error': '<reason>'} — do not proceed to XML generation.
Assemble a complete FatturaPA v1.2.3 XML document from all prepared blocks. Use this as step 10 in the invoice generation workflow — the final assembly step. All required blocks must come from their respective builder/validator tools; pass the full dict returned by each tool (the function unwraps the top-level key). Required: dati_trasmissione, cedente_prestatore, cessionario_committente, dati_generali, dettaglio_linee (list), dati_riepilogo (list from compute_totali()). Optional: dati_pagamento, allegati (list), dati_ritenuta. Does NOT validate against the XSD schema — call validate_fattura_xsd() (step 11) on the returned 'xml' string immediately after to confirm conformance. On success returns {'xml': str, 'filename': str, 'formato_trasmissione': str, 'length_bytes': int}. On unexpected error returns {'error': '<reason>'}.
Inconsistent tool naming: 'it__' prefix on 10 tools but absent on 4 (build_dati_generali, generate_fattura_xml, build_transmission_header, validate_cedente_prestatore). LLMs struggle with inconsistent naming conventions when selecting tools.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite explicit risk levels in metadata (WRITE, IRREVERSIBLE, READ_ONLY). Agents cannot infer safety properties without annotations.
Output schemas not documented for any tool. LLMs cannot plan downstream calls or extract required fields without knowing return structure. E.g., it__submit_to_sdi returns 'IdentificativoSDI' but this is not formally specified.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | <=2025-11-25 | v2 |
Archive a signed invoice for conservazione sostitutiva. Stores the document with SHA-256 hash, timestamp, and retention metadata per AgID circolare 65/2014. Returns the archive metadata including document_id and retention_until date.
Build a Pacchetto di Versamento (PdV) ZIP archive containing one or more signed invoices and an XML index (IPdV). The PdV is the unit of transfer to an AgID-accredited conservazione provider.
Check the status of a previously submitted invoice by its IdentificativoSDI. SDI communicates status asynchronously via notifications; this returns the last known local status.
Show current SDI channel configuration: environment, channel type, channel ID, endpoint URL, and certificate status. Does not expose sensitive values (cert_password).
List all archived invoices. Returns a list of archive metadata records sorted by archive date.
Parse an SDI notification XML into a structured dict. Supports all notification types: RC (delivery receipt), NS (rejection with error codes), MC (delivery failure), NE (seller outcome), EC (buyer acceptance/rejection), SE (outcome rejection), DT (deadline expiry), MT (metadata), AT (undeliverable attestation).
Retrieve an archived invoice by its document_id. Returns the document content (base64-encoded) and its archive metadata.
Send an acceptance (EC01) or rejection (EC02) notification to SDI for a received invoice. The esito XML must conform to the NotificaEsitoCommittente schema (MessaggiTypes_v1.1.xsd). Requires confirmation (irreversible).
Submit a signed FatturaPA invoice to SDI via SDICoop. The invoice must be signed (XAdES-BES or CAdES-BES) before submission. Requires mTLS certificate configuration. Returns the IdentificativoSDI assigned by SDI. Requires confirmation (irreversible).
Verify the integrity of an archived document by recomputing its SHA-256 hash and comparing against the stored hash.
Validate and build the CedentePrestatore (seller) block for FatturaPA. Use this as step 4 in the invoice generation workflow, after build_transmission_header() and before validate_cessionario(). Call get_regime_fiscale_codes() first if you need to look up the RF code. Gruppo IVA (VAT-group) sellers: when id_codice is a VAT-group IdFiscaleIVA, pass codice_fiscale set to the Codice Fiscale of the specific participating member company issuing this invoice, never the group's own CF. This mirrors the buyer-side rule enforced by SdI scarto code 00327 (see mcp_fattura_elettronica_it.sdi.notifications.SCARTO_CODE_REFERENCE); SdI does not publish an equivalent seller-side control code, but the same distinction applies structurally. Validates: either denominazione or both nome+cognome must be provided (mutually exclusive); regime_fiscale must be a valid RF01–RF19 code; Italian Partita IVA (id_paese='IT') must be exactly 11 digits; codice_fiscale, if provided, must be 16 alphanumeric characters (individuals) or 11 digits (companies).
Irreversible operations (it__submit_to_sdi, it__send_esito_committente) accept confirmation_token but lack clear guidance on how to obtain it or what happens if omitted. Confirmation flow is underdocumented.
Parameter descriptions for build_dati_generali and validate_cedente_prestatore are verbose (200+ chars) but lack formal constraints. E.g., 'tipo_documento must be a valid TD01 - TD28 code' should be an enum; 'numero must not exceed 20 characters' should be maxLength in schema.